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[Name of Document] SPECIFICATION 
[Title of the Invention] 

Infomiation Processing Apparatus, Inforomation Processing Method 
and Recording Medium 
[Claims] 

1 • An information processing apparatus comprising: 

first recording means for recording AV stream onto or into a recording 
medium; and 

second recording medium for recording, onto or into the recording 
medium, with the AV stream which has been recorded from a time point when 
recording of the AV stream has been started by the first recording means up to 
a time point when such recording has been completed being as one unit, at 
least one of information relating to recording mode of the AV stream, 
information relating to average value of recording rate of the AV stream, 
information relating to a time period where encoded information is the same 
of the AV stream, information realting to random-accessible position within 
the AV stream, and information realting to featured image within the AV 
stream, as attribute information of the AV streams, on the unit basis. 
2. The information processing apparatus according to claim 1, further 
including: 

creating means operative so that in the case where user gives an 



instruction to continuously reproduce a first AV stream and a second AV 
stream in the state where the streams of two units or more are recorded on or 
in the recording medium, the crating means serves to create a third AV stream 
consisiting of a predetermined portion of the first AV stream and a 
prodetermined portion of the second AV stream and reproduced when 
reproduction or playback is switched from the first AV stream to the second 
AV stream, 

wherein the first recording means records, as the AV stream, the third 
AV stream which has been created by the crating means, and 

the second recording means records, as the attribute information, 
attribute informationn of the third AV stream which has been created by the 
creating means. 

3. An information processing method including: 

a first recording control strep of controlling recording of AV stream; 

and 

a second recording control step of recording, with the AV stream in 
which recording has been controlled from a time point when control of 
recording of the AV stream has been started at processing of the first 
recording control step up to a time point when such control of recording has 
been completed being as one unit, at least one of information realting to 
recording mode of the AV stream, information relating to average value of 



recording rate of the AV stream, information relating to a time period when 
encoded information is the same of the AV stream, information relating to a 
random accessible position within the AV stream and inforamtion relating to 
featured image within the AV stream, as attribute information of 
corresponding AV stream, on the unit basis. 

4. A recording medium where computer readable progranmi is recorded, 
the computer readable program including: 

a first recording control strep of controlling recording of AV stream: 

and 

a second recording control step of recording, with the AV stream in 
which recording has been controlled from a time point when control of 
recording of the AV stream has been started at processing of the first 
recording control step up to a time point when control of recording has been 
completed being as one unit, at least one of information realting to recording 
mode of the AV stream, information realting to average value of recording 
rate of the AV stream, information relating to a time period where encoded 
information is the same of the AV stream, information relating to a random 
accessible position within the AV stream and information relating to featured 
image within the AV stream, as attribute information of corresponding AV 
stream,on the unit basis. 
[Detailed Description of the Invention] 
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[0001] 

[Technical Field of the Invention] 

The present invention relates to an information processing apparatus, 
an information processing method, and a recording medium. More 
particularly, the present invention relates to an information processing 
apparatus, an information processing method, and a recording medium which 
are adapted for recording, as file, address information of I picture, encoding 
parameter, change point information and/or information such as mark. 
[0002] 
[Prior Art] 

Recently, a variety of types of optical discs are being proposed as a 
disc-type recording medium that can be removed from a recording 
reproducing apparatus. These recordable optical discs have been proposed 
as a large capacity mediirai of several GBs and have high anticipation as 
media for recording AV (Audio Visual) signals. As the sources (supply 
sources) for digital AV signals to be recorded on the recordable optical disc, 
there are CS digital satellite broadcasting service and/or BS digital 
broadcasting services. In addition, ground wave television broadcasting 
services of the digital system have been also proposed. 
[0003] 

Here, it is general that digital video signals delivered from these 
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sources are ordinarily image-compressed in accordance with the MPEG 
(Moving Picture Experts Group) 2 system. Moreover, in the recording 
apparatus, recording rate specific to that apparatus is determined. In the case 
of recording digital video signals through the digital broadcasting service by 
conventional civilization image storage media, when the analog recording 
systemm is employed, digital video signal is decoded, and is then recorded 
after undergone bandwidth limitation. Altematively, when there is employed 
digital recording systems including MPEG 1 Video, MPEG 2 Video and DV 
system, a digital video signal is once decoded, and is then recorded after 
undergone re-encoding in accordance with the recording rate/encoding system 
specific to corresponding apparatus. 
[0004] 

However, in the case of such recording method, since bit stream 
delivered is once decoded and is then recorded after undergone bandwidth 
limitation or re-encoding, degradation of picture quantity would take place. 
In the case of recording image-compressed digital signal, when transmission 
rate of an inputted digital signal is not above a recording rate of the 
recording/reproducing apparatus, a method of recording a bit stream delivered 
as it is without performing decode or re-encode processing results in the fact 
that degradation of picture quality is the smallest. It should be noted that 
when transmission rate of image-compressed digital signal is above recording 
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rate of disc as recording medium, there is a necessity of decoding that digital 
signal by the recording/reproducing apparatus thereafter to perform 
re-encoding thereof so that transmission rate becomes equal to an upper limit 
or less of recording rate of the disc to record it. 
[0005] 

In addition, in the cse where transmission is performed in accordance 
the variable rate system in which bit rate of an input digital signal is increased 
or decreased with elapse of time, since the rotary head has fixed number of 
rotations, a disc recording apparatus adapted for once storing data into butter 
to have ability to record it in a burst manner can utilize cpacity of the 
recording medium without useless as compared to the tape recording system 
in which the recording rate is fixed rate. 
[0006] 

As stated above, it is predicted that, in the future where digital 
broadcasting service becomes main current, there are required 
recording/reproducing apparatuses adapted for recording digital signals as 
they are wityout decoding or re-encoding those digital signals, and using disc 
as recording medium as in the case of dtat streamer. 
[0007] 

[Problems to be solved by the invention] 

In resproducing a recording mediumin on which plural (data of 
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program consisting of plural data, e.g., video data and/or audio data, etc.) are 
recorded by apparatuses as described above, it is required to quickly perform 
processing such as determination of read-out position of AV stream and/or 
decoding of stream from a recording medium in response to instruction of 
random access or special reproduction by user. Howevewr, there was the 
problem that according as quantity of data recorded onto or into a recording 
medium is increased, it is impossible to quickly perform such a processing. 
[0008] 

The present invention has been made in view of such circimistances, 
and its object is to record, as file, address information of I picture, encoded 
parameter, change point information and/or information such as mark within 
AV stream to thereby have ability to quickly perform determination of 
read-out position and/or decode processing of AV stream. 
[0009] 

[Means for solving the problems] 

The information processing apparatus according to claim 1 comprise: 
first recording means for recording AV stream onto or into a recording 

medium; and 

second recording medium for recording, onto or into the recording 
medium, with the AV stream which has been recorded from a time point when 
recording of the AV stream has been started by the first recording means up to 
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a time point when such recording has been completed being as one unit, at 
least one of information relating to recording mode of the AV stream, 
information relating to average value of recording rate of the AV stream, 
information relating to a time period where encoded information is the same 
of the AV stream, information relating to a random-accessible position within 
the AV stream, and information relating to featured information within the AV 
stream, as attribute information of the AV streams, on the unit basis, 
[0010] 

The mformation processing apparatus further includes: creating means 
operative so that in the case where user gives an instruction to continuously 
reproduce a first AV stream and a second AV stream in the state where the 
streams of two imits or more are recorded on or in the recording medium, the 
creating means serves to create a third AV stream consisting of a 
predetermined portion of the first AV stream and a predetermined portion of 
the second AV stream and reproduced when reproduction or platback is 
switched from the first AV stream to the second AV stream, 

wherein the first recording means records, as the AV stream, the third 
AV stream which has been created by the creating means, and 

the second recording means records, as the attribute information, 
attribute information of the third AV stream which has been created by the 
creating means. 
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[0011] 

The information processing method according to claim 3 includes; a 
first recording control strep of controlling recording of AV stream; and a 
second recording control step of recording, with the AV stream in which 
recording has been controlled from a time point when control of recording of 
the AV stream has been started at processing of the first recording control step 
up to a time point when such control of recording has been completed being as 
one unit, at least one of information relating to recording mode of the AV 
stream, information relating to average value of recording rate of the AV 
stream, information relating to a time period where encoded information is the 
same of the AV stream, information relating to a random accessible position 
within the AV stream and information relating to featured image within the 
AV streams, as attribute information of corresponding AV stream, on the unit 
basis. 
[0012] 

The program for the recording medium according to claim 4 includes: 
a first recording control step of controlling recording AV stream; and a second 
recording control step of recording, with the AV streamin which recording has 
been controlled fi-om a time point when control of recording of the AV stream 
has been started at processing of the first recording control step up to a time 
point when such control of recording has been completed being as one xmit, at 
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least one of information relating to recording mode of the AV stream, 
information relating to average value of recording rate of the AV stream, 
information relating to a time period where encoded information is the same 
of the AV stream, information relating to a random accessible position within 
the AV stream and information relating to featured image within the AV 
streams, as attribute information of corresponding AV stream, on the unit 
basis. 
[0013] 

In the information processing apparatus according to claim 1, the 
information processing method according to claim 3, and the recording 
medium according to claim 4, with AV stream which has been recorded from 
the time point when recording of AV stream has been started up to the time 
point when such recording of AV stream has been completed being as one unit, 
at least one of information relating to recording mode of AV stream, 
information relating to average value of recording to rate of AV stream, 
information relating to the time period where encoded information is the same 
of the AV stream, information relating to the random accessible position 
within the AV stream, and information relating to featured image within the 
AV stream is or are recorded onto or into the recording medium as attribute 
information of the AV stream on the unit basis. 
[0014] 
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[Best Mode for Carrying out the Invention] 

The preferred embodiments of the present invention will now be 
explained in detail with refrence to the attached drawings. Fig.l is a view 
showing an example of the intemal configuration of a recording/reproducing 
apparatus 1 to which the present invention is applied. First, the configuration 
the portion for performing an operation to record signals input from the 
external will be explained. The recording/reproducing apparatus 1 is caused 
to be of the configuration supplied with analog or digital data to have ability 
to record such data. 
[0015] 

An analog video signals and an analog audio signal are respectively 
inputted to terminals 11, 12, respectively. The video signals, which has been 
inputted to the terminal 11, is outputted to each of an analysis unit 14 and to 
an AV encoder 15. The audio signal, which has been inputted to the terminal 
12, is outputted to the AV encoder 15. The analysis unit 14 extracts feature 
points such as scene changes, etc., from the inputted video. 
[0016] 

The AV encoder 1 5 encodes inputted video and audio signals to output 
the system information (S) such as encoded video stream (V), encoded audio 
stream (A) and AV synchronization, etc., to a multiplexer 16. 
[0017] 
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The encoded video stream is a video stream which has been encoded 
e.g., in accordance with the MPEG (Moving Picture Expert Group) 2 system, 
and the encoded audio stream is, e.g., an audio stream which has been 
encoded in accordance with the MPEGl system, an audio stream which has 
been encoded in accordance with the Dolby AC3 system. The multiplexer 
16 multiplexes the inputted video and audio streams on the basis of inputted 
system information to output a multiplexed stream to a multiplexed stream 
analysis unit 18 and to a source packetizer 19 through a switch 17. 
[0018] 

The multiplexed stream is e.g., an MPEG-2 transport stream or an 
MPEG2 program stream. The source packetizer 19 encodes the inputted 
multiplexed stream into an AV stream consisting of source packets in 
accordance with an application format of a recording medium 100 on which 
that stream is to be recorded. The AV stream is caused to undergo a 
predermined processing at an ECC (error correction and coding) unit 20 and a 
modulation unit 21. The AV stream thus obtained is outputted to a write unit 
22, Thus, the write unit 22 writes (records) an AV stream file onto the 
recording medium 100 on the basis of a control signal outputted from the 
controller 23. 
[0019] 

The transport stream of digital television broadcast, etc. which is 
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inputted from a digital interface or a digital television tuner, is inputted to a 
terminal 13. There are two recording systems for recording the transport 
stream inputted to the terminal 13, wherein those streams are a transparent 
recording system and a system of performing recording after re-encoding is 
implemented for the purpose of lowering the recording bit rate, etc. The 
recording system command information is inputted from a terminal 24 as a 
user interface to a controller 23. 
[0020] 

In the case of transparently recording an inputted transport stream, the 
transport stream which has been inputted to the terminal 1 3 is outputted to the 
multiplexed stream analysis unit 18 and to the source packetizer 19 through a 
switch 25. Since processing until AV stream is recorded onto the recording 
medium 100 at time subsequent thereto is the same processing in the case of 
encoding and recording the above-described analog inputted audio and video 
signals, those explanation is omitted. 
[0021] 

In the case where an inputted transport stream is re-encoded and is 
subsequently recorded, the transport stream which has been inputted to the 
terminal 13 is inputted to a demultiplexer 26 through a switch 35. The 
demultiplexer 26 implements demultiplex processing to the inputted transport 
stream to extract video stream (V), audio stream (A) and system information 
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(S). 
[0022] 

Among the streams (infomiation) which have been extracted by the 
demultiplexer 26, the video stream is outputted to an AV decoder 27, whilst 
the audio stream and the system information are outputted to the multiplexer 
16. The audio decoder 27 decodes the inputted video stream to output a 
reproduced video signal to the AV encoder 15. The AV encoder 15 encodes 
the inputted video signal to output the encoded video stream (V) to the 
multiplexer 16. 
[0023] 

On the other hand, the audio stream and the system information, 
which have been outputted from the demultiplexer 26 and have been inputted 
to the multiplexer 16, and the video stream, which has been outputted from 
the AV encoder 15, are multiplexed on the basis of input system information, 
and are outputted, as a multiplexed stream, to the multiplexed stream analysis 
unit 18 and to the sovirce packetizer 19 through switch 17. Since processing 
until an AV stream is recorded onto the recording medium 100 at times 
subsequent thereto is the same as that in the case of encoding and recording 
the above-described inputted audio and video signals, their explanation is 
omitted. 
[0024] 
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The recording/reproducing apparatus 1 of this embodiment records a 
file of the AV stream onto the recording medium 100, and also records the 
application database information which explains the file. This application 
database information is created by control unit 23. The input information to 
the controller 23 is the feature information for moving picture fi-om the 
analysis unit 14, the feature information of AV stream firom the multiplexed 
stream analysis unit 18 and the user command or instruction information 
inputted from the terminal 24. 
[0025] 

The feature information of the moving picture, which is supplied from 
the analysis unit 14, is information related to feature image within input 
moving picture signal, and is, e.g., designation information (mark), such as, 
for example, program start points, scene change points, CM commercial start 
and end points, and also includes information of thumbnail image of an image 
at the designated or specified portion. 
[0026] 

The feature information of the AV stream from the multiplexed stream 
analysis unit 18 is the information related to the encoded information of the 
AV stream to be recorded, and is, e.g., address information of the I-picture in 
the AV stream, encoding parameters of the AV stream and change point 
information of the encoding parameters in the AV stream, and information 
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(mark) related to feature image in video stream. 
[0027] 

The user designation information from the terminal 24 is the playback 
or reproduction period designated by the user, character letters for explaining 
the contents of the playback period, and/or the information such as bookmarks 
or resuming points which are set at favorite scene by user. 
[0028] 

On the basis of the aforementioned input information, the controller 
23 serves to create a database of the AV stream (Clip), a database of a group 
(PlayList) of playback periods (Playltem) of the AV stream, management 
information (info.drv) of recorded contents of the recording medium 100 
(info.dvr) and information of thumbnail images. Similarly to the AV stream, 
the application database information consisting of these information is 
processed at the ECC unit 20 and the modulation unit 21, and is then inputted 
to the write unit 22. The write unit 22 records a database file onto the 
recording medium 100 on the basis of a control signal outputted from the 
controller 23. 
[0029] 

The above-described application database information will be 
explained later in detail. 
[0030] 
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When the AV stream file (files of video data and audio data) and the 
application database information recorded on the recording medium 100 in 
this way are reproduced, the controller 23 first instructs a readout unit 28 to 
read out the application database information from the recording medium 100. 
Further, the readout unit 28 reads out the application database information 
from the recording medium 100. The application database information thus 
obtained is inputted to the controller 23 after undergone processing by a 
^ demodulating unit 29 and an ECC decoder 30. 
[0031] 

On the basis of application database information, the controller 23 
outputs a list of PlayList recorded on the recording medium 100 to a user 
interface of the terminal 24. The user selects the PlayList, which is desired 
to be reproduced, fi*om the list of PlayLists. The information relating to 
PlayList in which reproduction has been designated is inputted to the 
controller 23. The controller 23 instructs the readout unit 28 to read out the 
AV stream file necessary for reproducing the PlayList. In accordance with 
this instruction, the readout imit 28 reads out corresponding AV stream fi^om 
the recording medium 100 to output the AV stream thus obtained to the 
demodulating unit 29. The AV stream, which has been inputted to the 
demodulating unit 29, is caused to undergo a prdetermined processing so that 
it is decoded. Further, the AV stream thus obtained is outputted through the 
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processing by the ECC decoder 30 to a source depacketizer 3 1 . 
[0032] 

The source depacketizer 3 1 converts the AV stream of the application 
format, which has been read out from the recording medium 100 and has been 
caused to undergo a predetermined processing, into a stream which is 
permitted to be outputted to the demultiplexer 26. The demultiplexer 26 
outputs, to the AA^ decoder 27, the system information (S) such as the video 
stream (V), audio stream (A) and the AV synchronization, which constitute 
the playback period (Playltem) of the AV stream which has been specified by 
the controller 23. The AV decoder 27 decodes the video stream and the 
audio stream to output a reproduction video signal and a reproduction audio 
signal to each of corresponding terminals 32, 33. 
[0033] 

Moreover, in the case where information instructing random access 
reproduction or platback and/or special reproduction or playback is inputted 
from the terminal 24 as user interface, the controller 23 determines a readout 
position of the AV stream from the recording medium 100 on the basis of the 
content of the database (Clip) of the AV stream to instruct the readout imit 28 
to read out the AV stream thereof. For example, in the case where the 
PlayList which has been selected by user is reproduced from a predetermined 
time point, the controller 23 instracts the readout unit 28 to read out data from 

18 



an I-picture having a time stamp closest to the specified time point. 
[0034] 

Moreover, in the case where fast-forward playback is instructed by 
user, the controller 23 instructs the readout unit 28 to sequentially read out 
I-picture data in the AV stream in succession on the basis of database (Clip) of 
the AV stream. 
[0035] 

The readout unit 28 reads out data of the AV stream from a specified 
random access point. The data thus obtained is reproduced after undergone 
processing by respective units of the succeeding stages. 
[0036]. 

The case where the user edits AV stream recorded on the recording 
medium 100 will now be explained. In the case where user desired to 
specify a playback period of the AV stream recorded on the recording medium 
100, for example to prepare or create a new playback path, e.g., in the cxase 
where user desires to create such playback path to reproduce a portion of a 
singer A from the song program A to subsequently reproduce a portion of the 
singer A from the song program B, information indicating a start point 
(IN-point) and an end point (OUT-point) of the playback period is inputted to 
the controller 23 from the terminal 24 as a user interface. The controller 23 
serves to creates a database of the group (PlayList) of playback period 
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(Play Item) of the AV streams. 
[0037] 

In the case where user desires to delete a portion of the AV stream 
recorded on the recording medium 100, information of the IN-point and the 
OUT-point of the delete period is inputted to the controller 23. The 
controller 23 changes the database of the PlayList so as to refer to only the 
needed AV stream portions. In addition, the controller 23 also instructs the 
write unit 22 to delete an unnecessary stream portion of the AV stream. 
[0038] 

The case where the user desires to specify playback period of an AV 
stream recorded on the recording medium to prepare a new playback path, and 
desires to interconnect the respective playback periods in a seamless fashion 
will now explained. In such case, the controller 23 serves to create a 
database of a group (PlayList) of the playback period (Playltem) of the AV 
stream, and to further perform partial re-encoding and re-multiplexing of 
video stream in the vicinity of the connection point of the playback period. 
[0039] 

First, the information of picture at the IN-point and information of 
picture at the OUT-point of a playback period are inputted from the terminal 
24 to the controller 23. The controller 23 instructs the readout unit 28 to read 
out data necessary for reproducing the pictures at the IN-point and at the 
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OUT-point. Further, the readout unit 28 reads out data from the recording 
medium 100. The data thus read out is outputted to the demultiplexer 26 
through the demodulating imit 29, the ECC decoder 30 and the source 
packetizer 19. 
[0040] 

The controller 23 analyzes data which has been inputted to the 
demultiplexer 26 to determine the re-encoding method for the video stream 
(change of picture_coding_type and assignment of the quantity of encoding 
bits for re-encoding) and the re-multiplexing system to deliver the system thus 
determined to the AV encoder 15 and the multiplexer 16. 
[0041] 

The demultiplexer 26 then serves to separate the inputted stream into 
video stream (V), audio stream (A) and system information (S). As the 
video stream, there are "data to be inputted to the AV decoder 27" and "data to 
be inputted to the multiplexer 16". The former data is data necessary for 
performing re-encoding processing, and is decoded by the audio decoder 27. 
The decoded picture thus obtained is then re-encoded by the AV encoder 15 so 
that a video stream is provided. The latter data is data copied from an 
original stream without re-encoding. The audio stream and the system 
information are directly inputted to the multiplexer 16. 
[0042] 
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The multiplexer 16 multiplexes an input stream on the basis of 
information which has been inputted from the controller 23 to output a 
multiplexed stream. The multiplexed stream thus obtained is processed by 
the ECC unit 20 and the modulation unit 21, and is inputted to the write unit 
22. The write unit 22 records an AV stream onto the recording medium 100 
on the basis of control signals supplied from the controller 23. 
[0043] 

The application database information and the operation based on this 
information such as playback and editing will be explained below. Fig.2 is a 
view showing the structure of appHcation format. The application format has 
two layers, of PlayList and Clip, for AV stream management. The Volume 
Information performs management of all Clips and PlayLists within the disc. 
Here, pair of one AV stream and associated information thereof is considered 
as one object, and this is called Clip. The AV stream file is called a Clip AV 
stream file, and the associated information thereof is called the Clip 
Information file. 
[0044] 

For one Clip AV stream file, there is stored data in which MPEG-2 
transport stream is arranged so as to take a structure prescribed by the 
application format. In general, a file is treated as a byte string. The 
contents of the Clip AV stream file are expanded on the time axis, and entry 
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points in the Clip is mainly specified by the time basis. When a time stamp 
of an access point to a predeteraiined Clip is given, the Clip Infomiation file is 
useful for finding out address information at which data readout should be 
started in the Clip AV stream file. 
[0045] 

PlayList will now be explained with reference to Fig. 3. The 
PlayList is provided for selecting a playback period that user desires to see 
from the Clip to have ability to easily edit the playback period thus selected. 
One PlayList is a set of playback periods in the Clip. One playback period in 
a predetermined Clip is called Playltem and is represented by a pair of the 
IN-point and the OUT-point on the time axis. Accordingly, the PlayList is 
constitued by a set of plural Playltems. 
[0046] 

As the PlayList, there are PlayLists of two types. One type is Real 
PlayList and the other type is Virtual PlayList. The Real PlayList shares the 
stream portion of the Clip that it refers. Namely, the Real PlayList takes data 
capacity corresponding to a stream portion of the Clip that it refers, wherein 
when Real PlayList is deleted, data of a stream portion of the Clip that it refers 
is also deleted. 
[0047] 

The Virtual PlayList does not share Clip data. Accodingly, even if 
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the Virtual PlayList is changed or deleted, any change does not take place in 

the contents of the Clip, 

[0048] 

The editing of the Real Playlist will now be explained. Fig.4(A) is a 
view showing creation of Real PlayList. In the case where the AV stream is 
recorded as a new Clip, there results an operation in which the Real PlayList 
which refers the entire Clip thereof is a newly created. 
[0049] 

Fig.4(B) is a view relating to the division of the Real PlayList, and this 
operation is an operation in which the Real PlayList is divided at a desired 
point so that it is divided into two Real PlayLists, This division operation is 
performed when in such cases where management of two programs is 
performed within one clip which is caused to undergo management by a single 
PlayList, user intends to re-register or re-record programs as separate 
individual programs. This operation does not lead to change of the Clip 
contents (division of Clip itself). 
[0050] 

Fig.4(C) is a view relating to the combining operation of the Real 
PlayLists. This operation is an operation the operation of combining two Real 
PlayLists into one new Real PlayList. This combining operation is 
performed in such cases where, e.g., the user desires to re-register two 
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programs as a single program. This operation does not lead to change of the 

Clip (change into the case where there results one Clip by itself). 

[0051] 

Fig.5(A) is a view relating to deletion of the entire Real PlayList. In 
the case whre an operation to delete the entirety of a predtermined Real 
PlayList, the stream portion corresponding thereto of the Clip that the deleted 
Real PlayList refes is also deleted. 
[0052] 

Fig.5(B) is a view relating to partial deletion of the Real PlayList. In 
the case whre a desired portion of the Real PlayList is deleted, the Playltem 
corresponding thereto is changed so as to refer only a necessary Clip stream 
portion. Further, the corresponding stream portion of the Clip is deleted. 
[0053] 

Fig.5(C) is a view relating to the minimizing of the Real PlayList. 
This operation is an operation to refer the Playltem corresponding to the Real 
PlayList so as to refer only the stream portion of the Clip necessary for Wtual 
PlayList. The corresponding stream portion of the Clip which is not 
necessary for the Virtual PlayList is deleted. 
[0054] 

In the case where the Real PlayList is changed by an operation as 
described above so that the stream portion of the Clip that the Real PlayList 
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refers is deleted, there is a possibility that the Virtual PlayList which is using 
the deleted Clip exists and any problem may take place in the existing Virtual 
PlayList due to the deleted Clip, 
[0055] 

In order to prevent that such problem takes place, user is caused, with 
respect to operation of delete, to display such a message which notifies: ''If 
there exists Virtual PlayList which is referring the stream portion of the Clip 
that corresponding Real PlayList is refering, and when that Real PlayList is 
deleted, the Virtual PlayList itself is deleted - is it all right?" to thereby 
hasten confirmation (alarm) thereafter to execute processing of delete or 
cancel by user's instruction. Altematively, the minimizing operation is 
caused to be performed for the Real PlayList in place of deleting the Virtual 
PlayList. 
[0056] 

An operation for the Virtual PlayList will now be explained. Even if 
an operation is performed for the Virtual PlayList, the contents of the Clip is 
not changed. Fig.6 is a view relating to the assembling and editing (IN-OUT 
editing). This operation is an operation of creating Playltem of the playback 
period that the user has desired to see to create Virtual PlayList. The 
seamless connection between Playltems is supported by the application format 
(described later). 
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[0057] 

In the case where there exist two Real PlayLists 1, 2 and Clips 1, 2 
corresponding to the respective Real PlayLists, user specifies a predetermined 
time period in the Real PlayList 1 (period from INI to OUTl: Playltem 1) as 
the playback period, and also specifies, as the period to be reproduced next, a 
predetermined period in the Real PlayList 2 (period from IN2 to OUT2: 
Playltem 2) as the playback period as shown in Fig.6(A), a single Virtual 
PlayList consisting of Playltem 1 and the Playltem2 is created as shown in 
Fig.6(B). 
[0058] 

The re-editing of the Virtual PlayList will now be explained. As the 
re-editing, there are change of IN- or OUT points in the Virtual PlayList, 
insertion or appending of new Playltems into the Virtual PlayList, and 
deletion of Playltems in the Virtual PlayList. In addition, the Virtual 
PlayList itself may also be deleted. 
[0059] 

Fig.7 is a view relating to the audio dubbing (post recording) of audio 
to the Virtual PlayList. This operation is an operation to register the audio 
post recording to the Virtual PlayList as a sub path. This audio post 
recording is supported by the application software. An additional audio stream 
is added as a sub path to the AV stream of the main path of the Virtual 
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PlayList. 
[0060] 

As an operation common to the Real PlayList and the Virtual PlayList, 
there is an operation of changing (Moving) the playback order of the PlayList 
as shown in Fig.8. This operation is a change of the playback order of the 
PlayList in the disc (volume) and is supported by Table Of PlayList (which 
will be explained later with reference to Fig. 20, etc), which is defined in the 
application format. This operation does not lead to change of the Clip 
content. 
[0061] 

The mark (Mark) will now be explained. The mark is provided for 
specifying a highlight or characteristic time in the Clip and in the PlayList. 
The mark added to the Clip is e.g., a scene change point for specifying a 
characteristic scene resulting from the content in the AV stream. When the 
PlayList is reproduced, it may be used by referring the mark of Clip that 
corresponding the PlayList refers. 
[0062] 

The mark added to the PlayList is e.g., a bookmark point or a 
resuming point which is set mainly by user. Setting of the mark to the Clip 
and to the PlayList is performed by supplementing a tune stamp indicating 
mark time point to the mark list. On the other hand, mark deletion is 
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removing the time stamp of corresponding mark from the mark list. 
Accordingly, the AV stream is not changed by any means in accordance with 
mark setting or by mark deletion. 
[0063] 

A thumbnail will now be explained. The thumbnail is a still picture 
added to the Volume, PlayList and Clip. As the thumbnail, there are two 
kinds of thumbnails. One thumbnail is a thumbnail as a representative 
picture indicating the content- This is mainly used in a main picture in order 
to allow user to operate cursor (not shown), etc. to select a thin that he desires 
to see. The other thumbnail is an image indicating a scene that the mark 
points out. 
[0064] 

It is required that the Volume and the respective PlayLists can have 
representative pictures. It is supposed that the representative picture of the 
Volume is used in such cases where when disc (recording medium 100 which 
is assumed to be disc-shaped, and will be referred to as "disc" as occasion 
may demand) is set at a predetermined portion of the recording/reproducing 
apparatus 1, still picture representing the content of the disc is first displayed. 
It is supposed that the representative picture of PlayList is used as still picture 
for indicating the content of PlayList on the menu picture for selecting 
PlayList. 

29 



[0065] 

As the representative picture of the PlayList, it is conceivable that the 
initial image of the PlayList is employed as the thumbnail (representative 
picture). However, it is not necessarily limited that the leading picture at the 
playback time of 0 is an optimum picture in representing the content. In 
view of the above, the user is permitted to set an arbitrary image as a 
thumbnail of the PlayList. The above-mentioned two kinds of the 
thumbnails are called menu thumbnails. Since the menu thumbnails are 
displayed frequently, it is necessary to read out them at a high speed from the 
disc. For this reason, it is efficient to store all the menu thumbnails into a 
single file. It is not necessarily that the menu thumbnail is picture which has 
been extracted from the moving pictures in the volume, but may be a picture 
which has been taken thereinto from a personal computer or a digital still 
camera as shown in Fig. 10. 
[0066] 

On the other hand, it is necessary that plural marks are provided in the 
clip and the PlayList, whilst it is necessary for recorgnizing the content of the 
mark position to have ability to easily see image of mark point. The picture 
indicating such mark point is called a Mark Thiraibnail. Accordingly, image 
which gives basis of the thumbnail is main image from which image of mark 
point has been extracted rather than a picture which has been taken thereinto 

30 



from the external. 
[0067] 

Fig. 11 is a view showing the relation ship between mark attached to 
the PlayList and the mark thumbnail thereof, whilst Fig. 12 is a view showing 
the relationship between mark attached to the Clip and the mark thumbnail 
thereof. Since the mark thumbnail is used, in the menu thumbnail, at the 
time of displaying the detail of the PlayList, it is not requested that the mark 
thumbnail is read out in a short access time. For this reason, even if every 
time a thumbnail is required, the recording/reproducing apparatus 1 serves to 
open a file to read out a portion of that file so that it takes time to some extent, 
this does not constitute problem. 
[0068] 

Moreover, for the purpose of decreasing the number of files existing in 
a volume, it is preferable to store all the mark thumbnails into one file. 
While the PlayList may one menu thumbnail and plural mark thumbnails, 
since the user is not required to select the Clip directly (usually, the Clip is 
selected through PlayList), there is no necessity of providing menu 
thumbnails. 
[0069] 

Fig. 13 is a view showing the relationship of the menu thumbnails, 
mark thumbnails, PlayList and Clips in the case where the above-described 
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fact is taken into consideration. In the menu thumbnail file, there are filed 
menu thumbnails provided every PlayList. In the menu thumbnail file, there 
is included a volume thumbnail representing the content of data recorded on 
the disc. For the menu thumbnail file, there are filed or stored thumbnails 
created every PlayList and every Clip. 
[0070] 

The CPI (Characteristic Point Information) will now be explained. 
The CPI is data included in the Clip information file and is used mainly for 
finding out a data address where the data readout should be started in the Clip 
AV stream file when a time stamp of the access point to the Clip is given. In 
this embodiment, two kinds of CPIs are used, wherein one is EP_map and the 
other is TU_map. 
[0071] 

The EP_map is a list of entry point (EP) data, which is extracted from 
the elementary stream and the transport stream. This has address 
information fmdmg out the portion of entry point where decode operation 
should be started of the AV stream. One EP data consists of a pair of 
presentation time stamp (PTS) and data address in the AV stream of the access 
unit corresponding to that PTS. 
[0072] 

The EP_map is used mainly for two purposes. First, EP_map is used 
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for finding out data address in the AV stream in the access unit referred by the 
presentation time stamp in the PlayList. Secondly, the EP map is used for 
fast forward playback or fast reverse playback. In the case where the 
recording/reproducing apparatus 1 records the input AV stream when the 
syntax of the stream can be analyzed, the EP map is created and is recorded 
onto the disc. 
[0073] 

The TU_map has a list of time unit (TU) data which is based on the 
arrival time of the transport packet inputted through a digital interface. This 
provides the relationship between the arrival-time-based time and the data 
address in the AV stream. In the case where the recording and/or 
reproducing apparatus 1 records an input AV stream, when the syntax of that 
stream cannot be analyzed, TU map is created and is recordeded onto the 
disc. 
[0074] 

In this embodiment, the self-encoding stream format (SESF) is defined. 
The SESF is used for encoding analog input signals and for decoding digital 
input signals (e.g. DV) thereafter to encode the decoded signal into an 
MPEG-2 transport stream. 
[0075] 

The SESF defines encoding limit of an elementary stream pertinent 
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wi* respect .„ .he MPEG-2 Tanspon stream and the AV stream. When .he 
recording and/or reproducing apparatus lencodes and records input the SESF 
stream, EP_map is created and is recorded onto the disc. 
[0076] 

A digital broadoas. stream is recorded onto the recording medium .00 
by using either one of systems shown in below. Firs, the digital broadcast 
-earn is ttanscoded into an SESF st^am. In this case, the recorded stream 

must becomes in conformity with the SE<JF it. tu- 

y wim me bhSF. In this case, it is required that 

EP_map is created prepared and is recorded onto the disc. 

[0077] 

Al.en,a.ive.y. an elementaty stream constimting a digital broadcast 
stream is t.^scoded to a new elementa.^ stream and is re-multip,exed wi«, 
respect to a new transport st^am in confo^ity wift the stream fo™,at that the 
organization for standardizing the digital broadcast stream detennines. I„ 
*is case, it is req^red that EP_map is and is t^rded onto the disc. 

[0078] 

For example, i, is assumed 4at the input stream is MPEG-2 transport 
stream in confo^i., ^-.^ ^^^^^ ^^^^^^^^ 

iapan). which includes fte transport stream containing the HDTV video 
.ranscoded into SDTV video st.^ to re-multiplex the SDTV video stream 
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and the original AAC audio stream with respect to TS. The SDTV stream 
and the transport stream to be recorded must both become in conformity with 
the ISDB format, 
[0079] 

As another system of recording digital broadcast stream onto the 
recording medium 100, there is a susyem to make transparent recording of the 
input transport stream (to record the input tremsport stream unchanged), At 
that time, EP_map is created and is recorded onto the disc. 
[0080] 

Altematively, there is a system to transparently record the input 
transport stream to record input transport stream unchanged. At that time, 
TU_map is created and recorded onto the disc. 
[0081] 

The directory and the file will now be explained. The recording 
and/or reproducing apparatus 1 will be hereinafter described as DVR (Digital 
Video Recording) as occasion may demands. Fig. 14 is a view showing an 
example of directory structure on the disc. As the directories on the disc of 
the DVR, there are root directory including "DVR" directory, and the 
DVR" directory includmg "PLAYLIST" du-ectory, "CLIPINF" directory, 
"M2TS" directory and "DATA" directory as shown in Fig. 14, Although 
directories except for these directories may be created below the root directory, 
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these directories are assumed to be disregarded in the appHcation format of 

this embodiment. 

[0082] 

Below the "DATA" directory, there are stored all files and directories 
which are prescribed by the DVR application format. The "DVR" 
directory includes four directories. Below the "PLAYLIST" directory, 
there are are placed database fields of Real PlayList and Virtual PlayList. 
This directory may exist even if any PlayList exists only by one. 
[0083] 

Below "CLIPINF" , there is placed database of Clips. This directory 
also even if any Clip exists only by one. Below "M2TS" directory, there is 
placed AV stream files. This directory exists even if any AV stream file 
exists only by one. In the *'DATA" directory, there are stored files of data 
broadcast, such as digital TV broadcast. 
[0084] 

For the '*DVR" directory, files indicated below are stored, 
info.dvr" is created below the DVR directory to store the entire information 
of an application layer. Below the DVR directory, only one info.dvr must 
exist. The filename is assumed to be fixed to info.dvn For the 
menu.thmb" there is stored the information relating to the menu thumbnails. 
Below the DVR directory, there must exist 0 or one menu thumbnail. The 
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filename is assumed to be fixed to "menu.thmb" . In the case where any menu 

thumbnail exists only by one, this file may not exist. 

[0085] 

For the "mark.thmb" file, there is stored information pertinent to the 
mark thumbnail image. Below the DVR directory, there must exist 0 or 
one mark thumbnail. The filename is assumed to be fixed to "menu.thmb" . 
In the case where any menu thumbnail exists only by one, it is sufficient that 
this file does not exist. 
[0086] 

For the "PLAYLIST" directory, there is stored two kinds of the 
PlayList files which are Real PlayList and Virtual PlayList. In "xxxxx.rpls" 
file, there is stored information relating to one Real PlayList. Respective one 
files are created for respective Real PlayLists. The filename is "xxxxx.rpls" , 
wherein "xxxxx" denotes five niraierical figures from 0 to 9. It is assumed 
that file extension must be ''rpls" . 
[0087] 

For the "yyyyy.vpls" , there is stored the information relating to one 
Virtual PlayList. Respective one files are created every respective Virtual 
PlayLists. The filename is "yyyyy.vpls" here, "yyyyy" denotes five 
numerical figures from 0 to 9. It is assumed that file extension must be 
vpls" . 
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[0088] 

For the "CLIPINF" directory, there are stored respective one files in 
correspondence with each AV stream files. The "zzzzz.clpi" is a Clip 
Information file corresponding to one AV stream file (Clip AV stream file or 
Bridge-Clip stream file). The filename is "zzzzz.clpi" , wherein "zzzzz" 
denotes five numerical figures from 0 to 9. It is auumed that file extension 
must be "dpi" . 
[0089] 

For the "M2TS" directory, there is stored AV stream file. The 
zzzzz.m2ts" file is an AV stream file handled by the DVR system. This is 
Clip AV stream file or Bridge-Clip AV stream file. The filename is 
zzzzz.m2ts" , where "zzzzz" denotes five numerical figures from 0 to 9. It 
is assumed that file extension must be "m2ts" . 
[0090] 

For the "DATA" directory, there is stored data caused to imdergo 
transmission through data broadcasting. As such data, there are, e.g., XML 
or MPEG files. 
[0091] 

The syntax and the semantics of each directory (file) will now be 
explained. First, "info.dvr" directory will be explained. Fig. 15 is a view 
showing the syntax of the "info.dvr" file. The "info.dvr" file is made up 
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of three objects, which are DVRVoumeQ, TableOfPlayLists() and 

MakersPrivateData(). 

[0092] 

The syntax of info.dvr shown in Fig. 15 is explained. The 
TableOfPlayLists Start address indicates the leading address of the 
TableOfPlayListsQ with the relative number of bytes from the leading byte of 
the "info.dvr" file being as unit. The relative number of bytes is counted 
from 0. 
[0093] 

The MakersPrivateData Start_address indicates the leading address of 
the MakersPrivateDataO with the relative number of bytes from the leading 
byte of the "info.dvr" file being as unit. The relative number of bytes is 
counted from 0. The padding_word is inserted in association with the syntax 
of "info.dvr" . Nl and N2 are 0 or arbitrary positive integers. Each 
padding word may assume an arbitrary value. 
[0094] 

In the DVRVolumeO, there is stored the information which describes 
the contents of the volume (disc). Fig. 16 is a view showing the syntax of the 
DVRVolumeQ. The syntax of the DVRVolume(), shown in Fig: 16 will now 
be explained. The version number indicates four character letters indicting 
the version numbers of the DVRVolume(). The version_number is encoded 
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into ''0045" in accordance with ISO 646. 
[0095] 

length is represented by 32-bit unsigned integers indicating the 
number of bytes from immediately after the length field to the trailing end of 
DVRVolume(). 
[0096] 

In the ResumeVolumeO, there is stored the filename of the Real 
PlayList or the Virtual PlayList reproduced last in the Volume. It should be 
noted that the playback position when the user has interrupted playback of the 
Real PlayList or the Virtual PlayList is stored in the resume-mark defined in 
the PlayListMarkQ. 
[0097] 

Fig. 17 is a view showing the syntax of the Resume VolumeQ. The 
syntax of the Resume VolumeQ shown in Fig. 17 will be explained. The 
valid_flag indicates that the resume_PlayList_name field is valid when this 
1-bit flag is set to 1, and indicates that it is valid when this flag is et to 0. 
[0098] 

The 10-byte field of resume_PlayList_name indicates the filename of 
the Real PlayList or the Virtual PlayList to be resumed. 
[0099] 

In the UIAppInfo Volume in the syntax of the DVRVolume() shown in 
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Fig. 16, there are stored parameters of the user interface appHcation concerning 
the Volume. Fig. 18 is a view showing the syntax of the UIAppInfo Volume. 
The semantics thereof will now explained. The 8-bit field of character_set 
indicates the encoding method for character letters encoded in the 
Volume_name field. The encoding method corresponds to values shown in 
Fig. 19. 
[0100] 

The 8-bit field of the name_Iength indicates the byte length of the 
Volume name indicated in the Volume name field. The Volume name field 
indicates the name of the Volume. The number of bytes of name_length 
number from the left of the field indicates valid character letters and indicates 
the volume name. As values after these valid character letters in the Volume 
name fiels, any value may be inserted. 
[0101] 

The Volume_protect_flag is a flag indicating whether or not the 
contents in the Volume can be shown or pressented to the user without 
limitations. If this flag is set to 1, the contents of the Volume are permitted 
to be presented (reproduced) to the user only in case the user has succeeded in 
correctly inputting the FJN number (password). If this flag is set to 0, the 
contents of the Volume are permitted to be presented to the user even in case 
the PIN number is not inputted by the user. 
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[0102] 

At the time point when the user has first inserted a disc into a player, if 
this flag has been set to 0, or if user has succeeded in correctly inputting the 
PIN number even in the case where this flag is set to 1 , the recording and/or 
reproducing apparatus 1 demonstrates a list of the PlayList in the disc. The 
limitations on reproduction of the respective PlayLists are irrelevant to the 
volume_j>rotect_flag and are indicated by playback_control_flag defined in 
the UIAppInfo PlayList (). 
[0103] 

The PIN consists of four numerical figures of from 0 to 9, each of 
which is encoded in accordance with ISO/IEC 646. The 
ref_thumbnail_index field indicates the uiformation of a thumbnail image 
added to the Volume. If the ref thumbnail index field is a value except for 
OxFFFF, a thumbnail image is added to that Volume. The thumbnail image is 
stored in menu.thumb file. The image is referred by using the value of the 
ref_thumbnail_index in the menu.thumb file. If the ref_thumbnail_index 
field is OxFFFF, it is indicated that thimibnail image is not added to the 
Volume. 
[0104] 

The TableOfPlayListQ in the info.dvr syntax shown in Fig. 15 will now 
be explained. In the TableOflPlayList() there is stored the filename of the 
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PlayList (Real PlayList and Virtual PlayList), All PlayList files recorded in 
the Volume are included in the TableOfPlayList(). The TableOfPlayListQ 
indicates the playback order of the default of the PlayList in the Volume. 
[0105] 

Fig.20 is a view showing the syntax of the TableOfPlayList(). The 
syntax thereof will now be explained. The version number of the 
TableOfPlayListO indicates four character letters indicating the version 
numbers of the TableOfflayLists. The version niraiber must be encoded 
into "0045" in accordance with ISO 646. 
[0106] 

length is a unsigned 32-bit integer indicating the number of bytes of 
the TableOff layListO from immediately after the length field to the end of the 
TableOfPlayListO. The 16-bit field of the number_of_PlayLists indicates the 
number of loops of the for-loop inclusive of the PlayList_file_name. This 
numerical nxraiber must be equal to the number of PlayLists recorded in the 
Volume. The 10-byte numerical figure of the PlayList file name indicates 
the filename of the PlayList. 
[0107] 

Fig.21 is a view showing the configuration of another embodiment of 
the syntax of the TableOfPlayListQ, The syntax shown in Fig.21 is caused to 
be of the configuration inn which UI AppinfoPlayList (which will be 
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described later) is included into the syntax shown in Fig.20. By employing 
such configuration including the UIAppInfoPlayList, it becomes possible to 
create a menu picture only by reading out the TableOfPlayLists. The 
following explanation will be given on the premise that the syntax shown in 
Fig.20 is used. 
[0108] 

The MakersPrivateData in the syntax of the info.dvr shown in Fig. 15 
will now be explained. The MakersPrivateData is provided to permit the 
maker of the recording and/or reproducing apparatus 1 to insert private data of 
the maker in the MakersPrivateDataQ for special applications of respective 
makers. The private data of each maker has standardized maker_ID for 

identifying the maker which has defined it. The MakersPrivateData() may 

r 

include one or more maker_ID. 
[0109] 

In the case where a predetermined maker intends to insert private data, 
the private data of a different maker is already included in the 
MakersPrivateDataQ, the new private data is supplemented to the 
MakersPrivateDataQ in place of deleting the already existing old private data. 
Thus, in this embodiment, private data of plural makers are permitted be 
included in one MakersPrivateDataQ. 
[0110] 



44 



Fig.22 is a view showing the syntax of the MakersPrivateData. The 
syntax of the MakersPrivateData shown in Fig.22 will be explained. The 
version number thereof indicates four character letters indicating the version 
numbers of the TableOfPlayLists. The version_number must be encoded 
into "0045" in accordance with ISO 646. Length is a unsigned 32-bit integer 
indicating the number of bytes of the MakersPrivateDataQ from immediately 
after the length field to the end of the MakersPrivateData(). 
[0111] 

The mpd_blocks_start_address indicates the leading byte address of 
the first mpd_block() with the number of relative bytes from the leading byte 
of the MakersPrivateDataO being as unit. The number_of_maker entries is 
the 16-bit unsigned integer which provides the number of entries of the maker 
private data included in the MakersPrivateDataQ. There must not exist two or 
more maker private data having the same makerJD values in the 
MakersPrivateDataQ . 
[0112] 

The mpd_blocks_size is a 16-bit unsigned integer which provides the 
size of one mpd_block with 1024 bytes being as unit. For example, if 
mpd_block size = 1, it is indicated that the size of one mpd_block is 1024 
bytes. The number_of_mpd blocks is a 16-bit unsigned integer which 
provides the number of mpd blocks included in the MakersPrivateDataQ. 
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The maker_ID is the 16-bit unsigned integer indicating manufacturing maker 
of the DVR system which has created the maker private data. The value 
encoded into the maker lD is specified by the licensor of this DVR format. 
[0113] 

The maker model code is a 16-bit unsigned integer indicating the 
model number code of the DVR system which has created the maker private 
data. The value encoded into the maker_model_code is set by the 
manufacturing maker which has received the license of the format. The 
start mpd block number is a 16-bit unsigned integer indicating the number 
of the mpd block number at which the maker private data is started. The 
leading end of the maker private data must be aligned with the leading end of 
the mpd_block. The start_mpd_block_number corresponds to variable j in 
the for-loop of the mpd_block. 
[0114] 

The mpd_length is a 32-bit unsigned integer indicating the size of the 
maker private data on byte basis. The mpd_block is an area in which maker 
private data is stored. All of the mpd blocks in the MakersPrivateDataQ 
must have the same size. 
[0115] 

The Real PlayList file and the Virtual PlayList file, in other words, 
xxxxx.rpls and yyyyy.vpls, will now be explained. Fig.23 is a view showing 
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the syntax of xxxxx.rpls (Real PlayList) and yyyyy.vpls (Virtual PlayList), 
which are of the same syntax structure. Each of the xxxxx.rpls and 
yyyyy.vpls consists of three objects, which are PlayList(), PlayListMark() and 
MakersPrivateData(). 
[0116] 

The PlayListMark_Start address indicates the leading address of the 
PlayListMarkO with the number of relative bytes from the leading portion of 
the PlayList file being as a unit. The relative number of bytes is counted 
from zero. 
[0117] 

The MakersPrivateData Start address indicates the leading address of 
the MakersPrivateDataO with the relative number of bytes from the leading 
portion of the PlayList file being as a unit. The number of relative bytes is 
counted from zero. 
[0118] 

The padding word (padding word) is inserted in accordance with the 
syntax of the PlayList file, wherein Nl and N2 are arbitrary positive integers. 
Each padding word may take an arbitrary value. 
[0119] 

PlayList will be fiirther explained although it has been already 
explained briefly. Each playback term in all Clips except Bridge-Clip (which 
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will be described later) must be referred by all PlayLists existing in the disc. 
In addition, two Real PlayLists or more are such that the playback terms 
shown by their Playltems must not overlap with each other in the same Clip. 
[0120] 

Explanation will be further given with reference Fig.24C. For all 
Clips, there exist corresponding Real PlayLists as shown in Fig.24(A). This 
rule is observed also after the editing work has been performed as shown in 
Fig.24(B). Accordingly, all Clips must be viewed by referring any one of 
Real PlayLists. 
[0121] 

As shown Fig.24(C), the playback period of the Virtual PlayList must 
be included in the playback period and in the Bridge-Clip playback term. It 
is required to prohibit that disc Bridge-Clip which is not referred by any 
Virtual PlayList exists. 
[0122] 

The Real PlayList includes the list of the Playltem, but must not 
include SubPlayltem. The Virtual PlayList includes the Playltem list. In 
the case where the CPI_type shown in the PlayList() is the EP_map type and 
the PlayList type is 0 (PlayList including video and audio) , the Virtual 
PlayList may include one SubPlayltem. In the PlayListQ in this embodiment, 
the SubPlayltem is used only for audio post recording. The number of the 
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SubPlayltems owned by one Virtual PlayList must be 0 or 1 . 
[0123] 

The PlayList will now be explained. Fig.25 is a view showing the 
PlayList syntax. The version number indicates four character letters 
indicting the version numbers of the PlayList(). It is required that the 
version_number is encoded into "0045" in accordance with ISO 646. Length 
is a 32-bit unsigned integer indicating the number of bytes of the PlayListQ 
from immediately after the length field to the end of the PlayList(). The 
PlayList_type, is an 8-bit field indicating the PlayList type, and one example 
thereof is shown in Fig. 26. 
[0124] 

The CPI type is one-bit flag, which indicates the value of the 
CPI_type of the Clip referred by the Playltem() and by the SubPlayltemQ. 
The CPI_types defined in the CPIs of all Clips referred by one PlayList must 
have the same values. The number_of_PlayItems is a 16-bit field indicating 
the number of Playltems existing in the PlayList. 
[0125] 

The Playltem_id corresponding to a predetermined Playltem() is 
defined by the order in which the PlayltemQ appears in the for-loop including 
the Playltem(). The Playltem id is started fi-om 0. The 
nimber_of_SubPlayItems is a 16-bit field indicating the number of 
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SubPlayltems in the PlayList. This value is 0 or 1. An additional audio 

stream path (audio stream path) is a sort of a sub path. 

[0126] 

The UIAppInfoPlayList of the PlayList syntax shown in Fig.25 will 
now be explained. For the UIAppInfoPlayList, there are stored parameters 
of the user interface application with respect to the PlayList. Fig.27 is a view 
showing the syntax of the UIAppInfoPlayList. The syntax of 
UIAppInfoPlayList shown in Fig. 27 will now be explained. The 
character_set is an 8-bit field, which indicates a method for encoding 
character letters encoded in the PlayList name field. The encoding method 
corresponds to values in conformity with the table shown in Fig. 19. 
[0127] 

The name_length is an 8-bit field, which indicates the byte length of 
the PlayList name indicated in the PlayList_name field. The PlayList_name 
field shows the name of the PlayList. The number of bytes of the number of 
the name length from the left in the field is valid characters and indicates 
name of the PlayList. As values after those valid character letters, any value 
may be inserted. 
[0128] 

The record_time_and_date is a 56-bit field for storing the date and 
time where the PlayList was recorded. This field is 14 numerical figures for 
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year/ month/ day/ hour/minute/ second encoded in binary coded decimal 
(BCD). For example, 2001/ 12/ 23:01:02:03 is encoded into " 
0x20011223010203". 
[0129] 

The duration is a 24-bit field indicating the total replay time of the 
PlayList in terms of hour/ minute/ second being as a unit. In this field, six 
numerical figures are encoded in binary coded decimal (BCD). For example, 
01:45:30 is encoded into "0x014530". 
[0130] 

The valid ^period is a 32-bit field indicating the time periods where the 
PlayList is valid. This field is an area where 8 numerical figures are encoded 
in 4-bit binary coded decimal (BCD). For example, the recording 
reproducing apparatus 1 is used such that the PlayList, for which the valid 
period has lapsed, is automatically erased. For example, 2001/05/07 is 
encoded into "0x20010507'' . 
[0131] 

The maker_ID is a 16-bit unsigned integer indicating the maker of the 
DVR player (recording/reproducing apparatus 1) which has updated its 
PlayList last. The value encoded into maker ID is assigned to the licensor of 
the DVR format. The maker_code is a 16-bit unsigned integer indicating the 
model number of the DVR player which has updated the PlayList last. The 
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value encoded into the maker_code is determined by the maker which has 

received the license of the DVR format. 

[0132] 

In the case where the flag of the playback_control_flag is set to 1 , its 
PlayList is reproduced only when the user can correctly input the PIN number. 
If this flag is set to 0, the user may view the PlayList without the necessity of 
inputting the PIN number. 
[0133] 

In the case where the write_protect_flag is set to 1 as the table is 
shown in Fig. 28(A), the content of the PlayList is not deleted or changed 
except the write_protect__flag. If this flag is set to 0, the user can freely 
delete or change the PlayList. If this flag is set to 1, the 
recording/reproducing apparatus 1 serves to display such a message to 
perform re-confirmation before the user deletes, edits or overwrites the 
PlayList. 
[0134] 

The Real PlayList, in which the write_protect_flag is set to 0, may 
exist, the Virtual PlayList, which refers the Clip of the Real PlayList may exist, 
and the write_protect_flag of the Virtual PlayList may be set to 1 . If the user 
intends to delete the Real PlayList, the recording/reproducing apparatus 1 
issues an alarm to the user as to the existence of the aforementioned Virtual 
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PlayList or "Minimizes" the Real PlayList before erasing the Real PlayList. 
[0135] 

In the case where is_played__flag is set to 1, as shown in Fig.28B, it is 
indicated that the PlayList has been reproduced at least once since it has been 
recorded, whereas, if it is set to 0, it is indicated that the PlayList is not 
reproduced even once since it has been recorded. 
[0136] 

archive is a two-bit field indicating whether the PlayList is an original 
or a copy as shown in Fig.28C. The field of ref thumbnail index indicates 
the information of thumbnail image representative of the PlayList. If the 
ref_thumbnail_index field is a value which is not OxFFFF, a thumbnail image 
representative of the PlayList is added to the PlayList, and the PlayList is 
stored in the menu.thmb file. That image is referred by using the value of 
ref_thumbnail_index in the menu.thmb file. If the ref_thumbnail_index 
field is OxFFFF, no thumbnail picture representative of the PlayList is added 
to the PlayList. 
[0137] 

The Playltem will now be explained. One Playltem() elementarily 
includes the following data: Clip_Information_file_name for specifying the 
filename of the Clip, pair of IN-time and OUT-time specifying the playback 
period of Clip; STC_sequence_id that IN-time and OUT-time refer in the case 

53 



where the CPI_type defined in PlayList() is EP_map type, and 
Connection_Condition indicating the connection condition of previous 
Playltem and current Playltem. 
[0138] 

When PlayList consists of two Playltems or more, these Playltems are 
arrayed in a row, without temporal gap or overlap, on the global time axis of 
the PlayList. When CPI_type defined in the PlayList is EP_map type and the 
current PlayList does not have the BridgeSequence(), the pair of IN-time 
and OUT-time must indicate the same time on the STC continuous domain as 
that specified by the STC_sequence_id. Such an example is shown in 
Fig.29. 
[0139] 

Fig.30 shows the case where when the CPI_type defined in the 
PlayListQ is EP_map type and the current Playltem has the BridgeSequenceQ, 
the rules as now explained are applied. The DSf_time of the Playltem 
previous to the current Playltem (shown as IN_timel in the figure) indicates 
the time on the STC continuous period specified by the STC_sequence of the 
previous Play Time. The OUT_time of the previous Playltem (shown as 
OUT time lin the figure) indicates the time in Bridge-Clip specified in the 
BridgeSequencelnfoO of the current Playltem. This OUT_time must be in 
conformity with the encoding limitations which will be explained later. 
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[0140] 

^§nt Playltem (shown at IN_time2 in the figure) 
indicates t% specified in the BridgeSequencelnfoQ of the 
current Pl^jjje also must be in conformity with the 
encoding lijjj explained later. The OUT_time of 
Playltem (shown as OUT_time2 in the figure), 

indicates tfe gjC continuous period specified by 

STC_sequen|t Playltem. 
[0141J 

If the [ist() is TU_map type, pair of the IN_tmie and 
OUTjime o^ the time on the same Clio AV stream, as 
shown in Fig.3i 
[0142] 

The Plfjg as shown in Fig.32. The syntax of the 
Playltem sho| will be explained. The field of the 
Chp_informatic|icates the filename of the Clip Information 
file. The CI? defined by the ClipInfo() of this Clip 
Information file 4e Clip AV stream. 
[0143] 

ihe STd is an 8-bit field and indicates the 
STC_sequenceJ<iontinuous period that the Playltem refers. If 
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the CPI_type specified in the PlayListQ is TU_map type, this 8-bit field is not 
significant and is set to 0. IN_time is a 32-bit field and used to store the 
playback start time of Play Item. The semantics of E^^time varies depending 
upon CPI type defined in the PlayList() as shown in Fig.33. 
[0144] 

OUT_time is a 32-bit field and is used to store the playback end time 
of Playltem. The semantics of the OUT_time varies depending upon 
CPI type defined in the PlayListQ, as shown in Fig.34. 
[0145] 

Connection_condition is a 2-bit field indicating the connection 
condition between the previous Playltem and the current Playltem, as shown 
in Fig.35. Fig36 is a view showing respective states of 
Connection^Condition shown m Fig.35. 
[0146] 

BridgeSequencelnfo will now be explained with reference to Fig.37. 
This BridgeSequencelnfo is the ancillary information of the current Playltem 
and has the following information. Namely, the BridgeSequencelnfo includes 
Bridge_Clip AV file and a Bridge-Clip_Information_file_name specifying 
Clip Information file corresponding thereto. 
[0147] 

Moreover, when corresponding address is an address of a source 
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packet on the Clip AV stream that the previous Playltem refers. The first 
source packet of the Bridge-Clip AV stream is comiected subsequently to the 
source packet. This address is called the RSPN_exit_from_previous_Clip. 
Further, when corresponding address is also an address of the source packet 
on the Clip AV stream that the current Playltem refers. The last source 
packet of the Bridge Clip AV stream file is connected before the source 
packet. This address is called RSPN enter_to_current_Clip. 
[0148] 

In Fig.37, RSPN_arrival_time_discontinuity indicates an address of a 
source packet where a discontinuous point of the arrival time base exists in the 
Bridge-Clip AV stream file. This address is defined in the ClipInfo(). 
[0149] 

Fig.38 is a view showing the syntax of the BridgeSequencelnfo. The 
the syntax of BridgeSequencelnfo shown in Fig.38 will be explained. The 
field of Bridge_Clip_Information_file_name indicates the filename of the Clip 
Information file corresponding to the Bridge-Clip AV stream file. The 
Clip_stream_type defined in ClipInfoQ of this Clip information file must 
indicate ' Bridge-Clip AV stream ' . 
[0150] 

The 32-bit field of the RSPN exit_fi'om_previous_Clip is a relative 
address of a source packet on the Clip AV stream that the previous Playltem 
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refers. The first source packet of the Bridge-Clip AV stream file is 
connected subsequently to this source packet. The 
RSPN_exit_from j)revious_Clip has a size in which the source packet number 
is caused to be a unit, and is counted with the value of the ofifset_SPN defined 
in the ClipInfo() from the first source packet of the Clip AV stream file that 
the previous Playltem refers being as an initial value. 
[0151] 

The 32-bit field of RSPN_enter_to_curent_Clip is the relative address 
of the source packet on the Clip AV stream that the current Playltem refers. 
The last source packet of the Bridge_Clip_AV stream file is connected before 
this source packet. The RSPN_enter_to_curent_Clip has a size that is based 
on the source packet number is caused to be a unit, and is counted with the 
value of the offset_SPN defined in the ClipInfo() from the first source packet 
of the Clip AV stream file the current Playltem refers being as an initial value. 
[0152] 

The SubPlayltem will now be explained with reference to Fig.39. 
The use of SubPlayltemQ is permitted only if the CPI_type of the PlayListQ is 
the EP_map type. In this embodiment, SubPlayltem is used only for audio 
post recording. The SubPlayltemQ includes the following data. First, it 
includes Clip_Information_file_name for specifying the Clip that the sub path 
in the PlayList refers. 
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[0153] 

Moreover, SubPlayItem() also includes SubPathlNtime and 
SubPath_OUT_time for specifying the sub path playback period in the Clip. 
Further, it includes sync_PlayItem_id and start_PTS_of_PlayItem for 
specifying the time at which reproduction or playback of the sub path is 
started on the time axis of the main path. The Clip AV stream, which is 
referred by the sub path, must not contain STC discontinuous points 
(discontinuous points of the system time base). The clocks of audio samples 
of the Clip used in the sub path are locked into the clocks of the audio samples 
of the main path. 
[0154] 

Fig.40 is a view showing the syntax of the SubPlayltem. The syntax 
of the SubPlayltem shown in Fig.40 will be explained. The field of the 
Clip_Information_file_name indicates the filename of the Clip Information 
file and is used by a sub path in the PlayList. The Clip_stream_type defined 
in the ClipInfo() of this Clip Information file must indicate the Clip AV 
stream. 
[0155] 

An 8-bit field of SubPath_path indicates the sub path type. Here, 
only '0x00' is set, as shown in Fig.41, while other values are reserved for 
future use. 
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[0156] 

The 8-bit field of sync PlayItem_id indicates the Playltem id of the 
Playltem in which the time at which reproduction or playback of the sub path 
is started on the time axis of the main path. The value of Playltem_id 
corresponding to a predtermined Playltem is defined in the PlayList() (see 
Fig-25). 
[0157] 

A 32-bit field of sync_start_PTS_of_PlayItem indicates the time at 
which reproduction or playback of the sub path on the time axis of the main 
path, and indicates the upper 32 bits of the PTS (presentation time stamp) on 
the Playltem referenced by the sync__PlayItem_id. For the upper 32 bit field 
of the SubPath_IN_time, there is stored the playback start time of the sub path. 
SubPath_IN_time denotes upper 32 bits of the PTS of 33 bit length 
corresponding to the first presentation unit in the Sub Path. 
[0158] 

For the upper 32 bit field of subPath_OUT_time, there is stored the 
playback end time of the Sub path, SubPath OUT time indicates upper 32 
bits of the value of the Presentation_end_TS calculated by the following 
equation: 

Presentation_end_TS = PTS_OUT + AU__duration 
where PTS_out is the PTS of the 33 bit length corresponding to the last 
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presentation unit of the SubPath, and AU duration is the 90 kHz based 

display period of the last presentation unit of the SubPath. 

[0159] 

PlayListMarkO in the syntax of xxxxx.rpls and yyyyy-vpls shown in 
Fig.23 will now be explained. The mark information relating to the PlayList 
is stored in this PlayListMark. Fig.42 is a view showing the syntax of 
PlayListMark. The syntax of the PlayListMark shown in Fig.42 will be 
explained. The version number is four character letters indicating the version 
number of this PlayListMark(). The version_number must be encoded into 
"0045" in accordance with ISO 646. 
[0160] 

length is an unsigned 32-bit integer indicating the number of bytes of 
PlayListMarkO from immediately after the length field to the trailing end of 
the PlayListMarkO. The number_of_PlayListMarks is a 16-bit unsigned 
integer indicating the number of marks stored in the PlayListMark. The 
number_of_PlayListMarks may be zero. The mark_type is an 8-bit field 
indicating the mark type and is encoded in accordance with the table shown in 
Fig.43. 
[0161] 

For the 32-bit filed of mark_time_stamp, there is stored a time stamp 
indicating the point at which the mark has been designated. The semantics 
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of the mark_time_stamp vary depending upon CPI_type defined in the 
PlayListQ, as shown in Fig.44. The Playltem id is an 8-bit field specifying 
the Playltem where the mark is put. The values of Playltem_id 
corresponding to a predetermined Playltem is defined in the PlayList() (see 
Fig.25). 
[0162] 

An 8-bit field of character_set indicates an encoding method for 
character letters encoded in the mark name field. The encoding method 
corresponds to values shown in Fig. 19. The 8-bit field of name length 
indicates the byte length of the mark name shown in the Mark__name field. 
The Mark nEime field indicates the mark name. The number of bytes of 
name length number from the left in this field is the valid character letters and 
indicates the mark name. As values after those valid character letters in the 
Mark_name field, any value may be set. 
[0163] 

The field of the ref_thumbnail index indicates the information of the 
thumbnail picture added to the mark. If the field of the ref thumbnail index 
is a value which is not OxFFFF, a thumbnail picture is added to its mark. That 
picture image is stored in the mark.thmb file. This picture image is referred 
in the mark.thmb file by using the value of ref_thumbnail_index which will be 
explained later. If the ref_thumbnail_index field is OxFFFF, it is indicated 
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that no thumbnail picture is added to that mark. 
[0164] 

The Clip Information file will now be explained. The zzzzz.clpi 
(Clip Information file) consists of six objects, as shown in Fig-45. They are 
ClipInfoO, STCJnfoQ, ProgramlnfoQ, CPIQ, ClipMark() and 
MakersPrivateDataQ. For the AV stream (Clip AV stream or Bridge-Clip AV 
stream) and Clip Information file corresponding thereto, the same string of 
numerals '*zzzzz" is used. 
[0165] 

The syntax of zzzzz.clpi (Clip Information file) shown in Fig.45 will 
be explained. The ClipInfo_Start address indicates the leading address of 
ClipInfoO with the relative number of bytes from the leading end byte of the 
zzzzz.clpi file being as a unit. The relative number of bytes is counted from 
zero. 
[0166] 

The STC Info Start_address indicates the leading address of 
STC_Info() with the relative number of bytes from the leading end byte of the 
zzzzz.clpi file as a unit. The relative number of bytes is counted from zero. 
The ProgramInfo_Start_address indicates the leading address of 
ProgramlnfoO with the relative number of bytes from the leading end byte of 
the zzzzz.clpi file being as a unit. The relative number of bytes is counted 
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from 0. The CPI_Start_address indicates the leading address of CPI() with 
the relative number of bytes from the leading end byte of the zzzzz.clpi file as 
a unit. The relative number of bytes is counted from zero. 
[0167] 

The ClipMark_Start_address indicates the leading end address of 
ClipMark() with the relative number of bytes from the leading end byte of 
the zzzzz.clpi file as a unit. The relative number of bytes is counted from zero. 
The_MakersPrivateData Start_address indicates the leading end address of 
MakersPrivateDataQ with the relative number of bytes from the leading end 
byte of the zzzzz.clpi file as a unit. The relative number of bytes is counted 
from zero. The padding word is inserted in accordance with the syntax of 
the zzzzz.clpi file. Nl , N2, N3, N4 and N5 must be zero or arbitrary positive 
integers. The respective padding words may also assume arbitrary values. 
[0168] 

The Cliplnfo will now be explained. Fig.46 is a view showing the 
syntax of Cliplnfo. For the ClipInfo(), there is stored attribute information of 
AV stream file corresponding thereto (Clip AV stream or Bridge-Clip AV 
stream file). 
[0169] 

The syntax of the Cliplnfo shown in Fig.46 will be explained. The 
version_number is the four character letters indicating the version number of 
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Best Available Copy 



^ion number must be encoded to "0045" in 
accor(|g length is a 32-bit unsigned integer indicating 
the ni^jjj^foQ immediately after the length field to 
MipInfoQ. An 8-bit field of Clip_stream_type 
indicatti stream corresponding to the Clip Information file, 
as shoA^gjjjjj of AV streams of respective AV streams will 
be explai 

[0170] ; 

loffset_SPN gives an offset value of the source 
packet n^ource packet number of the AV stream (Clip AV 
stream oi;av stream). When the AV stream file is first 
recorded ifset_SPN must be zero. 
[0171] 

when the beginning portion of the AV stream file 
is deleted |fset_SPN may take values except for 0. In this 
embodime^ce packet number (relative address) which refers 
the offset 3; described in the syntax in the form of RSPNxxx 
(xxx may RSPN_EP_start). The relative source packet 
number has S with the source packet number is caused to be a 
unit and is q first source packet number of the AV stream file 
with the valu5PN being as the initial value from the first source 
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packet of the AV stream file. 
[0172] 

The number of source packets from the first source packet of the AV 
stream file to the source packet referred by the relative source packet number 
(SPN_xxx) is calculated by the following equation: 

SPN^xxx = RSPN^xxx - offset^SPN. 
An example of the case SPN_xxx is 5 is shown in Fig. 49. 
[0173] 

TS_recording_rate is a 24-bit unsigned integer, and this value gives an 
input/output bit rate required for the AV stream to the DVR drive (write unit 
22) or from the DVR drive (readout unit 28). The record time and date is a 
56-bit field for storing the date and time when the AV stream corresponding to 
the Clip is recorded and is a field in which 14 numerical figures are encoded 
by 4-bit Binary Coded Decimal (BCD) with respect to 
year/month/day/hour/minute binary coded decimal (BCD) for 14 numerical 
figures. For example, 2001/2/23:01:02:03 is encoded into " 
0x20011223010203" . 
[0174] 

The duration is a 24-bit field indicating the total playback time of the 
Clip in units of hour/minute/second based on arrival time clocks. This field 
is an area where six numerical figures are encoded by 4-bit binary coded 
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decimal (BCD). For example, 01 :45:30 is encoded into "0x014530" . 
[0175] 

A flag of time controlled_£lag indicates the recording mode of an AV 
stream file. If this time_controlled_flag is 1, it is indicated that the recording 
mode is a mode where recording is performed in such a manner that the file 
size is proportionate to the time elapsed since recording. This recording 
mode must satisfy the condition shown by the following equation: 
Ts_average_rate*192/188*(t - start_time)- a <= size_clip(t) 

<=TS__average_rate* 192/1 88*(t - start_time) + a 
where TS_average_rate is a value in which average bit rate of the transport 
stream of the AV stream file is expressed in units of bytes/second. 
[0176] 

Moreover, in the above equation, t indicates the time represented in 
second unit, while start_tmie is the time point when the first source packet of 
the AV stream file has been recorded. The size__clip(t) is a value in which 
size of AV stream file at time t is represented in byte units. For example, in 
the case where ten Source packets are recorded fi-om Start time to time t, 
size_clip(t) is 10*192 bytes and a is a constant dependent on 
TS average_rate. 
[0177] 

In the case where time_controlled_flag is set to 0, it is indicated that 
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the recording mode is a mode where control is not performed such that the 
time lapse of recording and the file size of the AV stream are proportional to 
each othen For example, this is the case where input transport stream is 
recorded in a transparent fashion. 
[0178] 

In the case where time_controlled flag is set to 1, the 24-bit field of 
TS_average_rate indicates the value of TS_average_rate used in the above 
equation. If time controlled flag is set to 0, this field is not significant and 
must be set to 0. For example, the variable bit rate transport stream is 
encoded by the following procedure: First, the transport rate is set to the value 
of TS_recording rate. Then, the video stream is encoded by the variable bit 
rate. Further, the transport packet is intermittently encoded resulting from 
the fact that no null packet is used. 
[0179] 

The 32-bit field of RSPN_arrival_time discontinuity is a relative 
address of a location where arrival timebase discontinuity takes place on the 
Bridge-Clip AV stream file. The RSPN_arrival__time_discontinuity has a 
size in which the source packet number is caused to be a unit and is counted 
with the value of offset_SPN defined in the ClipInfoQ as from the first source 
packet of the Bridge-Clip AV stream file being as initial value. An absolute 
address in the Bridge-Clip AV stream file is calculated on the base of the 
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above-mentioned equation: 

SPN_xxx = RSPN_xxx - offset^SPN, 

[0180] 

The 144-bit field of reserver_for_system_use is reserved for system. 
If is_format_identifier valid flag is 1, it is indicated that the field of 
format_identifier is valid. If is_original network_ID valid flag is 1, it is 
indicated that the original_network_ID field is valid. If 
is__trqnsport stream ID valid flag is 1, it is indicated that the field of 
is_transport_stream_ID-valid is valid. If is_servece_ID_valid flag is 1 , it is 
indicated that the servece_ID field is valid. 
[0181] 

When is_country_code_valid flag is 1, it is indicated that the field of 
country code is valid. The 32-bit field of format__identifier indicates the 
value of format_identifier owned that registration descriptor (defined in 
ISO/IEC13818-1) has in the transport stream. The 16-bit field of 
transport_stream_ID indicates the value of the transport_stream_ID defined in 
the transport stream. 
[0182] 

The 16-bit field of servece_ID indicates the value of servece__ID 
defined in the transport stream. The 24-bit field of country code indicates a 
country code defined by IS03166. Each character code is encoded by 
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IS08859-1. For example, Japan is represented as "JPN" and is encoded 
into ''0x4 A 0x50 0x4E" . The stream format name is 16 character codes of 
ISO-646 showing the name of a format organization which performs stream 
definitions of transport streams. A value of ' OxFF' is set at invalid by to in 
this field. 
[0183] 

format__identifier, original_network_ID, transport^stream^ID, 
servece_ID, country_code and stream_format_name indicate service providers 
of transport streams. Thus, it is possible to recognize encoding limitations 
on audio or video streams and stream definitions of private data streams 
except for the standard of SI (service information) and/or audio/video streams. 
These information can be used for judging whether or not the decoder is able 
to decode the stream, whereby in the case where such decoding is possible, 
initialization of the decoder system is performed before decoding is started. 
[0184] 

STC_Info will now be explained. The time period in which STC 
discontinuous points (discontinuous points of the system time base) is not 
included in the MPEG_2 transport stream is called the STC_sequence. In 
the Clip, STC sequence is specified by the value of STC sequence id. Fig. 
50 is a view for explining a continuous STC period. The same STC values 
never appear in the same STC_sequence (it should be noted that the maximum 
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tine length of Clip is limited as explained below). Accordingly, the same 
PTS values also never appear in the same STC_sequence. If the AV stream 
includes N number of STC discontinuous points (N > 0), the Clip system time 
base is divided into (N+1) number of STC sequences. 
[0185] 

For the STC Info, there is stored address of a location where STC 
discontinuitie (system timebase discontinuities) takes place. As explained 
with reference to Fig.51, the RSPN_STC_start mdicates the address and the 
k-th (K>=0) STC_sequence except for the last STC_sequence begins from a 
time point ot which source packet referred by the (k+l)-th RSPN_STC_start 
has arrived and ends at the time point when the source packet referred by the 
k-th RSPN_STC_start has arrived. 
[0186] 

Fig.52 is a view showing the syntax of the STC_Info. The syntax of 
STC Info shown in Fig.52 will be explained. The version_number is four 
character letters indicating the version number of STC_Info(). The 
version_number must be encoded into "0045" in accordance with the ISO 
646. 
[0187] 

length is a 32-bit unsigned integer indicating the number of bytes of 
STC_Info() from immediately after this length field to the end of STC_Info. 

71 



If CPI type of CPI() indicates TU_map type, 0 may be set in this length field. 
If CPI_type of CPI() indicates EP_map type, the num of STC sequence mut 
be a value equal to 1 or more. 
[0188] 

An 8-bit unsigned integer of num_of_STC sequence indicates the 
number of sequences in the Clip. This value indicates the number of the 
for-loops subsequently to this field. The STC_sequence_id corresponding to 
a predetermined STC_sequence is defined by the order in which the 
RSPN STC start corresponding to that STC_sequence appears in the for-loop 
including the RSPN_STC_start. The STC_sequenceJd is started from 0. 
[0189] 

The 32-bit field of RSPN__STC_start indicates an address at which the 
STC_sequence begins on the AV stream file. The RSPN_STC_start 
indicates an address where discontinuity of system time base takes place in the 
AV stream file. The RSPN_STC_start may also be a relative address of the 
source packet having the first PGR of the new system time base in the AV 
stream. The RSPN_STC_start has a size in which source packet number is 
caused to be a unit and is counted from the first source packet of the AV 
stream file with the offset SPN value defined in ClipInfo() being as an initial 
value. The absolute address in the AV stream file is calculated by the 
above-mentioned equation, that is 
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SPN^xxx = RSPN_xxx - offset^SPN. 

[0190] 

Programlnfo in the syntax of zzzz.clip shown in Fig.45 will now be 
explained with reference to Fig.53. The time period having the following 
features in the Clip is called program^sequence. Initially the value of 
PCR_PID is not changed. Moreover, the number of audio elementary 
streams is not also changed. Further, the PID values in the respective video 
streams and the encoding information defined by the VideoCodinglnfo thereof 
are not changed. Furthermore, the number of audio elementary streams is 
not changed. In addition, the PID values of the respective audio streams are 
not changed, and the encoding information, defined by the AudioCodinglnfo 
thereof, are not changed. 
[0191] 

Program_sequence has only one system time base at the same time 
point. Program_sequence has a single PMT at the same time point. For the 
ProgramlnfoO, there is stored an address of a location where the 
program_sequence begins. RSPN__program_sequence-start indicates that 
address. 
[0192] 

Fig.54 is a view showing the syntax of Programlnfo. The 
Programlnfo shown in Fig.54, will be explained. The version_number is 
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four character letters indicating the version number of ProgramInfo(). The 
version_number must be encoded into "0045" in accordance with the ISO 
646. 
[0193] 

length is a 32-bit unsigned integer indicating the number of bytes of 
ProgramlnfoO from immediately after this length field to the end of 
program(info()- If CPI_type of CPI() indicates the TU_map type, this length 
field may be set to 0, If the CPI_type of CPIQ indicates EP_map type, the 
nimiber_of_programs must be a value equal to 1 or more. 
[0194] 

An 8-bit unsigned integer of number_of_program_sequences indicates 
the number of program_sequences in the Clip. This value indicates the 
number of for-loops subsequent to this field. In the case where 
program_sequence is not changed in the Clip, 1 must be set in the number of 
program_sequences. A 32-bit field of RSPN_program_sequence_start is a 
relative address of a location where the program sequence begins on the AV 
stream. 
[0195] 

RSPN_program_sequence_start has a size in which the source packet 
number is caused to be a imit and is counted with the value of ofiFset_SPN 
defined in the ClipInfoQ from the first source packet of the AV stream file 
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being as an initial value. The absolute address in the AV stream file is 
calculated by: 

SPN_xxx = RSPN_xxx - offset_SPN. 
The values of RSPN_program_sequence_start in the for-loop syntax must 
appear in the ascending order. 
[0196] 

A 16-bit field of PCR PID indicates the PID of the transport packet 
including valid PGR field in the program sequence. An 8-bit field of 
number_of videos indicates the number of for-loops including 
videostreamPID and VideoCodinglnfoQ. An 8-bit field of 
number_of_audios indicates the number of for loops including 
audio_stream_PID and AudioCodingIISffo(). A 16-bit field of 
video_stream_PID indicates the PID of the transport packet including valid 
stream in its program_sequence. VideoCodingInfo() subsequent to this field 
must explain the content of the video stream referred by its 
video_stream_PID. 
[0197] 

A 16-bit field of audio_stream_PID indicates the PID of a transport 
packet including valid audio stream in its program sequence. The 
AudioCodinglnfoQ subsequent to this field must explain the content of the 
video stream referenced by its audio__stream_PID. 
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[0198] 

It should be noted that the order in which values of video stream PID 
appear in the for-loop of the syntax must be equal to the order in which PIDs 
of the video stream are encoded in the PMT valid for the program_sequence. 
Moreover, the order in which values of audio_stream_PID appear in the 
for-loop of the syntax must be equal to the order in which PIDs of the audio 
stream are encoded in the PMT valid for the program_sequence. 
[0199] 

Fig.55 is a view showing the syntax of VideoCodinglnfo in the syntax 
of the Programlnfo shown in Fig.54. The syntax of the VideoCoding Info 
shown in Fig.55 will be explained. An 8-bit field of video format indicates 
the video format corresponding to video_stream_PID in ProgramlnfoO, as 
shown in Fig.56. 
[0200] 

As shown in Fig.57, an 8-bit field of frame_rate indicates the video 
frame rate corresponding to the video stream PID in ProgramlnfoQ. An 
8-bit field of display_aspect_ratio indicates a video display aspect ratio 
corresponding to video_stream_PID in ProgramlnfoQ as shown in Fig. 58. 
[0201] 

Fig.59 is a view showing the syntax of the AudioCodinglnfo in the 
syntax of the Programlnfo shown in Fig.54. The syntax of the AudioCoding 
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Info shown in Fig.59 will be explained. An 8-bit field of audio_coding 
indicates an audio encoding method corresponding to audio_stream_PID in 
ProgramlnfoO as shown in Fig.60. 
[0202] 

An 8-bit field of audio_component_type indicates an audio component 
type corresponding to audio_stream_PID in ProgramInfo() as shown in Fig.61. 
An 8-bit field of sampling_frequency indicates an audio sampling frequency 
corresponding to audio_stream_PID in ProgramInfo() as shown in Fig.62. 
[0203] 

The CPI (Characteristics Point Information) in the syntax of zzzzzxlip 
shown in Fig.45 will now be explained. The CPI is used for allowing the 
time information in the AV stream and the address in its file to be related with 
each other. The CPI is of two types, i.e., EP_map and TU_map. As shown 
in Fig.63, in the case where CPI_type in CPIQ is EP_map type, its CPIQ 
includes EP_map. In Fig.64, if CPI^type in CPI() is TU_map, its CPIQ 
contains TU_map. One AV stream has one EP map or one TU_map. In 
the case where the AV stream is an SESF transport stream. Clip correspondin 
thereto must have an EP_map. 
[0204] 

Fig.65 is a view showing the syntax of CPI. The syntax of CPI 
shown in Fig.65 will be explained. The version_number is four character 
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letters indicating the version number of this CPI(). The version_number 
must be encoded into *'0045" in accordance with the ISO 646. Length is a 
32-bit unsigned integer indicating the number of bytes from immediately after 
this length field to the trailing end of the CPI(). The CPI type is a 1-bit flag 
and indicates the CPI type of Clip as shown in Fig.66. 
[0205] 

The EP_map in the CPI syntax shown in Fig.65 will now be explained. 
There are two types of the EP_map, i.e., EP_map for a video stream and 
EP_map for audio stream. The EP_map_type in the EP_map differentiates 
between these EP_map types. If the Clip includes one video streams or more, 
the EP_map for the video stream must be used. If the Clip does not includes 
a video stream but includes one audio streams or more, the EP_map for the 
audio stream must be used. 
[0206] 

The EP_map for video stream will be explained with reference to 
Fig.67. The EP_map for the video stream has data of stream PID, 
PTS_EP_start and RSPN_EP_start. The stream_PID indicates the PID of the 
transport packet for performing transmission of a video stream. The 
PTS_EP_start indicates the PTS of an access unit beginning from the 
sequence header of the video stream. The RSPN_EP_start indicates the 
address of a source packet including the first byte of an access unit refereed by 
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the PTS_EP_start in the AV stream. 
[0207] 

A sub table, which is called EP_map_for_one_stream_PID(), is 
created every video stream caused to undergo transmission by transport packet 
having the same PID. In the case where plural video streams exist in the 
Clip, the EP_map may include plural EP_map_for_one_stream_PID(). 
[0208] 

The EP map for audio stream has data of stream PID, PTS EP start 
and RSPN_EP_start. The stream_PID indicates a PID of transport packet for 
performing transmission of audio stream. The PTS_EP start indicates the 
PTS of access unit of the audio stream. The RSPN_EP_start indicates an 
address of source packet including the first byte of the access unit referred by 
PTS_EP_start m the AV stream. 
[0209] 

The sub table, which is called EP_map_for_one_stream_PID(), is 
created every audio stream caused to imdergo transmission by the transport 
packet having the same PID. In the case where there exist plural audio 
streams in the Clip, EP_map may include plural 
EP_map_for_one_stream_PID(). 
[0210] 

The relationship between EP_map and STC_Info will be explained. 
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One EP_map_for_one_stream_PID() is created into one table irrespective of 
discontinuous points of the STC. By making comparison between the value 
of the RSPN_EP_start and the value of RSPN_STC_start defined in 
STC_Info(), the boundary of data of EP_map belonging to respective 
STC sequences can be understood (see Fig.68). The EP_map must have one 
EP_map_for_one_stream_PID with respect to continuous stream range caused 
to undergo transmission by the same PID. As shown in Fig.69, program#l 
and program#3 have the same video PID. However, the data range is not 
continuous, so that EP_map_for_one_stream_PID must be provided for each 
program. 
[0211] 

Fig.70 is a view showing the syntax of the system of EP_map. The 
syntax of the EP_map shown in Fig.70 will be explained. The EP_type is a 
4-bit field and indicates the entry point type of the EP_map entry point type, 
as shown in Fig.71. The EP_type indicates the semantics of data field 
subsequent to this field. In the case where Clip includes one video stream or 
more, the EP_type must be set to 0 ( Video' ). Altematively, in the case 
where the Clip does not include no video stream, but includes one audio 
stream or more, EP_type must be set to 1 ( * audio' ). 
[0212] 

The 16-bit field of number_of_stream_PIDs indicates the number of 
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times of loops of the for-loop having number_of_stream_PIDs in the 
EP mapO as a variable. The 16-bit field of stream_PID(k) indicates the FID 
of the transport packet for performing transmission of the k-th elementary 
stream (video or audio stream) referred by EP_map_for_one_stream_PID 
(num_EP_entries(k)). In the case where EP type is 0 ( * video' ), its 
elementary stream must be video stream. In addition, in the case where 
EP_type is equal to 1 ( 'audio' ), its elementary stream must be the audio 
stream. 
[0213] 

The 16-bit field of num_EP_entries(k) indicates the 
num_EP_entries(k) referenced by EP_map_for_one_atream_PID, 
num_EP_entries(k)). The EP_map_for_one_stream_PID_ Start_address(k) : 
This 32-bit field indicates the relative address position at which the 
EP_map_for_one_stream_ PID(num_EP_entries(k)) begins in the EP__map(). 
This value is indicated by the size as from the first byte of the EP_map(), 
[0214] 

padding_word must be inserted in accordance with the syntax of 
EP_map(). X and Y must be zero or arbitrary positive integers. The 
respective padding words may take arbitrat value. 
[0215] 

Fig.72 is a view showing the syntax of EP_map_for_one_stream_PID. 
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.ip_for_one_stream_PID shown in Fig.72 will be 
®^P^^f the 32-bit field of PTS_EP_start vaiy depending 
"P°"|iin the EP_map(). In the case where EP_type is 
®*^"^'ield has upper 32 bits of the 33-bit accuracy PTS of 
^c^ith sequence header of the video stream. In the 
^^^^ ^Iqual to 1 ( 'audio' ), this field has upper 32 bits of 
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?je access unit of the audio stream. 
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ie 32-bit field of RSPN_EP_start vary depending 

il 
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EP_map(), In the case where EP_type is equal 
^ ( ijindicates the relative address of the source packet 
including sequence header of the access unit referred by 
the PTSj^Y stream. Alternatively, in the case where 
^^-.typ& ijio* ), this field indicates the relative address of the 
source pal g^st byte of the audio stream of the access unit 
referred b|t in the AV stream. 

[0217J 1; 

a size in which the source packet number is 
caused to b) counted fi-om the first source packet of the AV 
stream file, |-the ofFset_SPN, defined in ClipInfoQ being as an 
mitial value.,address m the AV stream file is calculated by 
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SPN^xxx = RSPN_xxx - ofiFset^SPN. 

It is noted that the value of the RSPN EP start in the syntax must 
appear in the ascending order. 
[0218] 

The TU_map will now be explained with reference to Fig.73. 
TU__map creates a time axis on the basis of arrival time clock of source packet 
(time of the arrive time base). This time axis is called TU_map_time_axis. 
The origin of TU_map time axis is indicated by offset time in the TU mapQ. 
TU_map_time_axis is divided into predetermined units from ofifset_time. This 
unit is called time_unit. 
[0219] 

In each time_unit in the AV stream, addresses on the AV stream file 
of the first source packet in the complete form are stored in TU_map. These 
addresses are called RSPN_time_unit_start. The time at which the k(k >= 
0)-th time_unit on the TU_map_time_axis is called TU_start_time(k). This 
value is calculated on the basis ofifoUowing equation: 

TU_start_time(k) = ofiFset_time + k*time_umt_size. 

In this case, TU_start_time(k) has accuracy of 45 kHz. 

[0220] 

Fig.74 shows the syntax of TU_map. The TU__map syntax shown in 
Fig.74 will be explained. The 32-bit length field of ofiFset_time gives an offset 
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time with respect to TU_map_time_axis. This value indicates the offset time 
with respect to the first time unit in the Clip. The ofFset_time has a size in 
which 45 kHz clock derived from the 27 MHz accuracy arrival time clocks 
being as a unit. In the case where the AV stream is recorded as new Clip, 
offset_time must be set to 0. 
[0221] 

The 32-bit field of time unit size gives the size of the time_unit, and 
has a size in which 45 kHz clocks derived from the 27 MHz accuracy arrival 
time clocks being as a unit. It is preferably that time_unit_size is sett o one 
second or less (time_unit_size <= 45000). The 32 bit field of 
number_of_time_xmit_entries indicates the number of entries stored in 
TU_map(). 
[0222] 

The 32-bit field of RSN_time_unit_start indicates the relative address 
of a location where each time_unit begins in the AV stream. 
RSPN_time_unit_start has a size in which the source packet number is caused 
to be a unit and is coxmted with the value of offset_SPN defined in ClipInfoQ 
from the first source packet of the AV stream file being as an initial value. 
The absolute address in the AV stream file is calculated by 

SPN_xxx = RSPN_xxx - ofifset_SPN. 

It is noted that the value of RSPN_time_unit_start in the for-loop of 
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the syntax must appear in the ascending order. Ifn the case where there is no 
source packet in the (k+l)-th time unit, the (k+l)-th RSPN_time__unit_start 
must be equal to the number k-th RSPN time unit start. 
[0223] 

The ClipMark in the syntax of zzzzz.clip shown in Fig.45, will be 
explained. The the ClipMark is the mark information with respect to clip 
and is stored in the ClipMark. This mark is not set by a recorder 
(recording and/or reproducing appeiratus 1), but is not set by user. 
[0224] 

Fig.75 is a view showing the syntax of the ClipMark. The syntax of 
the ClipMark shown in Fig.75 will be explained. The version_number is 
four character letters indicating the version number of this ClipMark. The 
version number must be encoded into "0045" in accordance with the ISO 
646. 
[0225] 

length is a 32-bit unsigned integer indicating the number of bytes of 
the ClipMarkO as from immediately after the length field to the end of 
ClipMark(). The number_of_Clip_marks is a 16-bit unsigned integer 
indicating the number of marks stored in the ClipMark. The 
number of Clip marks may be equal to 0. Mark type is an 8-bit field 
indicating the mark type and is encoded in accordance with the table shown in 
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Fig.76. 
[0226] 

mark_time_stamp is a 32-bit field and stores the time stamp indicating 
a pointer in which a mark has been designated. The semantics of 
mark_time_stamp varies depending upon CPI type in the PlayList(), as shown 
in Fig.77. 
[0227] 

In the case where CPI_type in CPI() indicates the EP^map type, this 
8-bit field of STC_sequence_id indicates the STC_sequence_id of the STC 
continuous period where marks are placed. In the case where CPI_type in 
CPI() indicates TU__map type, this 8-bit field has no meaning but is set to 0. 
The 8-bit field of character_set indicates the an encoding method of character 
letters encoded in the mark_name field. The encoding method corresponds 
to the value shown in Fig. 19. 
[0228] 

The 8-bit field of name_length indicates the byte length of the mark 
name shown in the Mark_name field. This mark_name field indicates the 
name of mark. The number of bytes of the name_length number from the 
left in this field is valid character letters and indicates the mark name. As 
values after those valid character letters in the mark_name field, any value 
may be inserted. 
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[0229] 

The field of ref thumbnail index indicates information of the 
thumbnail picture added to the mark. In the case where the 
ref_thumbnail_index field is a value which is not values of OxFFFF, thumbnail 
picture is added to its mark, and the thumbnail picture is stored in the 
mark.thumb file. This picture is referred by using the value of 
ref_thumbnaiMndex in the mark.thumb file. In the case where the 
ref_thumbnail_index field is OxFFFF, thumbnail picture is not added to its 
mark. 
[0230] 

Since MakerPrivateData has been already explained with reference to 
Fig.22, its explanation will be omitted. 
[0231] 

Then, thumbnaiMnformation will be explained. A thumbnail picture 
is stored in a menu.thmb file or in a mark.thmb file. These files are of the 
same syntax structure and have a single Thumbnail(). For the menu.thmb 
file, there is stored a menu thumbnail picture, picture representing Volume and 
picture representing respective PlatyLists. All menu thumbnails are stored 
into only one menu.thmb file. 
[0232] 

For the mark.thmb file, there is stored a mark thumbnail picture, i.e., a 
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picture representing a mark point. All mark thumbnails with respect all 
PlayLists and Clips are stored in only one mark.thmb file. Since the 
thumbnails are frequently added or deleted, the operations of addition and 
partial deletion are able to be easily executed at a high speed. For this reason, 
ThmbnailQ has a block structure: Picture data is divided into several 
portions each of which is stored in one tn_block. One picture data is stored 
in successive tn_blocks. In the train of tn blocks, there may exist tn_block 
which is not used now. The byte length of one thumbnail picture is variable. 
[0233] 

Fig.78 is a view showing the syntax of the menu.thmb and the 
mark.thmb, and Fig.79 is a view showing the syntax of the Thumbnail in the 
syntax of the menu.thmb and the mark.thmb. The syntax of the Thmbnail 
syntax shown in Fig79 will be explained. The version number is the four 
character letters indicating the version number of this Thumbnail(), The 
version number must be encoded into "0045'' in accordance with the ISO 
646. 
[0234] 

length is a 32-bit unsigned integer indicating the number of bytes of 
MakersPrivateData from immediately after the length field to the end of 
Thumbnail(). tn block_start_address is a 32-bit unsigned integer indicating 
the leading byte address of the first tn block, with the relative number of 
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bytes from the leading byte of Thumbnail() being as unit. The relative 
number of bytes is counted from 0. number_of_thumbnails is a 16-bit 
unsigned integer which provide the number of entries of thumbnail pictures 
included in the Thumbnail(). 
[0235] 

tn_block_size is a 16-bit unsigned integer which provides one 
tn_block size with 1024 bytes being as a unit. For example, if 
tn_block_size = 1, it is indicated that the size of one tn_block is 1024 bytes. 
number_of_tn_blocks is a 16-bit unsigned integer representing the number of 
entries of tn_blocks in the Thumbnail(). thumbnail_index is a 16-bit 
unsigned integer representing the index number of a thumbnail picture 
represented by thimibnail information corresponding to one for-loop 
beginning from this thvimbnail_index field. The value of OxFFFF must not 
be used as thumbnail_index. The thumbnail_index is referred by 
ref_thumbnail_index in the UIAppInfVblume(), UIAppInfoPlayList(), 
PlayListMarkO and ClipMarkQ. 
[0236] 

thumbnail_jDicture_format is an 8-bit unsigned integer representing the 
picture format of thumbnail picture and takes values shown in Fig.80. "DCF 
and PNG" in the table are permitted only in "menu_thumb" . The mark 
thumbnail must take value "0x00" (MPEG-2 Video I-picture). 
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[0237] 

picture data size is a 32-bit unsigned integer indicating the byte 
length of a thumbnail picture on byte basis. start_tn_block_number is a 
1 6-bit unsigned integer indicating tn_block number of the tn__block where data 
of thumbnail picture begins. The leading portion of the thumbnail picture 
data must be in correspondence with the leading end of tn^block. The 
tn__block number begins from 0 and is related to the value of variable k in the 
for-loop of the tn_block. 
[0238] 

x_picture_length is a 16-bit unsigned integer representing the number 
of pixels in a horizontal direction of a frame picture of the thumbnail picture. 
y_picture_length is a 16-bit unsigned integer representing the number of 
pixels in the vertical direction of the frame picture of the thumbnail picture. 
tn_block is an area in which a thumbnail picture is stored. All tn_blocks in 
ThumbnailO are of the same size (fixed length) and their sizes are defined in 
size by tn block size. 
[0239] 

Fig. 81 is a view showing, in a model form, how thumbnail picture 
data are stored in tn_block. As shown in Fig,81, the respective thumbnail 
picture data begin from the leading portion of tn__block. In the case where 
picture data is above one tn_block, it is stored by using the successive 
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subsequent tn block. By performing storage in this way, management of 
picture data which has variable size is permitted as fixed length data. Thus, it 
becomes possible to comply editing such as deletion by simple processing 
operation. 
[0240] 

AV stream file will now be explained. The AV stream file is stored 
in "M2TS" directory (Fig. 14). There are two types of the AV stream files, 
and those streams are Clip AV stream and Bridge-Clip AV stream. Both AV 
streams must be of the structure of D VR MPEG-2 transport stream file which 
will be hereinafter defined. 
[0241] 

First, the DVR MPEG-2 transport stream will now be explained. 
The structure of DVR MPEG-2 transport stream is as shown in Fig. 82. The 
AV stream file has the structure of a DVR MPEG-2 transport stream. The 
DVR MPEG 2 transport stream consists of plural Aligned imits. The 
Aligned unit has a size of 6144 bytes (= 2048*3 bytes). The Aligned unit 
begins fi"om the first byte of the source packet. The source packet has a length 
of 192 bytes. One source packet consists of TP_extra__header and transport 
packet. The TP_extra_header has 4 bytes length, and has 188 bytes length. 
[0242] 

One Aligned unit consists of 32 source packets. The last Aligned 
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unit in the DVR MPEG-2 transport stream also consists of 32 source packets. 
Thus, the DVR MPEG-2 transport stream is terminated at a boundary of the 
Ahgned unit. When the number of the transport packets of the input 
transport stream recorded on the disc is not a muhiple of 32, source packet 
having null packet (transport packet of PID = OxlFFF) must be used as the 
last Aligned unit. In the file system, it is not prohibited to add excess 
information to the DVR MPEG-2 transport stream. 
[0243] 

The recorder model of the DVR MPEG-2 transport stream is shown in 
Fig. 83. The recorder shown in Fig.83 is a conceptual model for prescribing a 
recording process. The DVR MPEG-2 transport stream is in conformity with 
this model. 
[0244] 

The input timing of the MPEG-2 transport stream will be explained. 
The input MPEG-2 transport stream is full transport stream or partial transport 
stream. The input MPEG-2 transport stream to be inputted must be in 
accordance with the ISO/IEC13818-1 or ([2]) ISO/IEC 138 18-9 ([5]). The 
i-th byte of the MPEG-2 transport stream is inputted at time t(i) 
simultaneously to both a T-STD (Transport stream system target decoder 
prescribed by the ISO/IEC 13818-1) 51 and a source packetizer. Rpk is an 
instantaneous maximum value of the input rate of the transport packet. 
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[0245] 

A 27 MHz PLL52 generates a frequency of 27 MHz clocks. The 
jfrequency of 27 MHz clock is locked at a value of PGR (Program Clock 
Reference) of the MPEG-2 transport stream. An arrival time lock counter 53 
is a binary counter serving to count pulses having a frequency of 27 MHz. 
The arrival time_clock(i) is a count value of the Arrival time clock counter at 
time t(i). 
[0246] 

A source packetizer 54 serves to add TP_extra_header to all transport 
packets to create a source packet. Arrival_time_stamp indicates times at 
which the first byte of the transport packet arrives at both the T-STD and the 
source packetizer. ArrivaMime_stamp(k) is a sample value of the 
Arrival_time_clock(k) as indicating by the following equation: 

arrival_time_stamp(k) = arrival_time_clock(k)% 2^^ 
where k indicates the first byte of the transport packet. 
[0247] 

In the case where the time interval of two successively inputted 
transport packets becomes equal equal to 2^^/27000000 sec (about 40 sec), the 
difference between the arrival_time_stamps of the two transport packets 
should be set to 2^^/27000000 sec. The recorder is provided for the case where 
there results such situation. 
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[0248] 

A smoothing buffer 55 serves to performe smoothing of the bitrate of 
the input transport stream. The smoothing buffer 55 should not be allowed 
to overflow. Rmax is an output bitrate of a source packet from the smoothing 
buffer 55 when the smoothing buffer 55 is not in an empty state. When the 
smoothing buffer 55 is void in the empty state, the bitrate of output from the 
smoothing buffer 55 is zero. 
[0249] 

The parameters of a recorder model of the DVR MPEG-2 transport 
stream will now be explained. The value of Rmax is given by 
TS_recording_rate defined in ClipInfo() corresponding to the AV stream file. 
This value is calculated in accordance with the following equation: 

Rmax = TS_recording_rate* 1 92/1 88 
where the value of TS_recording_rate has a size in which bytes/second is 
caused to be a unit. 
[0250] 

In the case where the input transport stream is SESF transport stream, 
Rpk must be equal to TS_recording_rate defined in ClipInfo() corresponding 
to the AV stream file. In the case where the input transport stream is not 
SESF transport stream, there may be referred, as this value, values defined in 
descriptors of the MPEG-2 transport stre£im, e.g., 
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maxi^ or partial_transport_stream_descriptor. 
[025 1^ 

s input transport stream is SESF transport stream, 
the siz^Q-gj. 55 (smoothing buffer size) is zero. In the 
case v«iQj^ stream is not SESF transport stream, values 
defined Qf the MPEG-2 transport stream, e.g., 
smooth|.^ short_smoothing_bugger_descriptor or 

P^^^Llcriptor, etc. may be referred as the size of the 

smoothiij 

[0252] 

-Reorder) and a reproducing unit (player) are each 
required Ija sufficient size. The default buffer size is 1 536 
bytes, ; 
[0253J 

Tl| the DVR MPEG-2 transport stream will now be 
explained.|r showmg the player model of the DVR MPEG-2 
transport conceptual model for prescribing the replay or 

reproductioi DVR MPEG-2 transport stream is in conformity 

with this me 

[0254] 

A 27generates a frequency of 27MHz. The error range 
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of the 27 MHz frequency must be ± 30 ppm (27000000±810 Hz). An 
arrival time clock counter 62 is a binary counter serving to count pulses 
having a frequency of 27 MHz. Arrival_time_clock(i) is a count value of the 
Arrival time clock counter at time t(i). 
[0255] 

In the smoothing buffer 64, Rmax is an input bitrate of a source packet 
to the smoothing buffer v^hen the smoothing buffer is not in full state. When 
the smoothing buffer is in full state, the input bitrate to the smoothing buffer is 
zero. 
[0256] 

The output timing of the MPEG-2 transport stream will be explained. 
When arrival_time_stamp of the current source packet is equal to the value of 
the 30 LSB bits of arrival_time_clock(i), the transport packet of the source 
packet is extracted from the smoothing buffer. Ppk is an instantaneous 
maximum value of the transport packet rate. The smoothing buffer should 
not be allowed to overflow. 
[0257] 

The parameters of the player model of the DVR MPEG-2 transport 
stream are the same as the parameters of the recorder model of the 
above-described DVR MPEG-2 transport stream. 
[0258] 
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Fig. 85 is a view showing the syntax of the Source packet. 
transport_packet() is an MPEG-2 transport packet prescribed in ISO/IEC 
13818-1. The syntax of the TP_Extra_header shown in Fig. 86 will now be 
explained. copy_permission_indicator is an integer representing copy 
limitations of the payload of the transport packet. The copy Hmitations may 
be set to copy free, no more copy, copy once or copy prohibited. Fig.87 
shows the relation ship between values of copy_permission_indicator and the 
modes designated by these values. 
[0259] 

copy_permission_indicator is added to all transport packets. In the 
case where an input transport streeim is recorded by using the IEEE 1394 
digital interface, the value of copy_permission_indicator may be related to the 
value of EMI (Encryption Mode Indicator) in the IEEE 1394 isochronous 
packet header. In the case where input transport stream is recorded without 
using the IEEE 13 94 digital interface, the value of copy_permission_indicator 
may be related to the value of the CCI embedded in the transport packet. In 
the case of performing self-encoding of an analog signal input, the value of 
the copyjpermission_indicator may be related to the value of CGMS-A of 
analog signal. 
[0260] 

Arrival_time_stamp is an integer value having a value specified by 
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arrival_time_stamp in the following equation. 

arrival_time stamp(k) = aiTival_time_clock(k)%230. 

[0261] 

In order to define Clip AV stream, the Clip AV stream must have the 
structure of the DVR MPEG-2 transport stream in which definition as 
described above is made. arrival_time_clock(i) must increase continuously 
in the Clip AV stream. Even if a discontinuous point of the system time base 
(STC base) exists in the Clip AV stream, the arrival_time_clock(i) of that Clip 
AV stream must increase continuously. 
[0262] 

The maximum value of the difference of the arrival_time_clock(i) 
between the beginning and the end in the Clip AV stream must be 26 hours. 
This limitation guarantees that in the case where there exists no discontinuous 
point of the system time base (STC base) in the MPEG-2 transport stream, 
PTS (Presentation Time Stamp) of the same value never appears in the Clip 
AV stream. The MPEG2 system standards prescribes that the wraparound 
period of PTS should be 233/90000 sec (about 26.5 hours). 
[0263] 

In order to define the Bridge-Clip AV stream, the Bridge-Clip AV 
stream must have the structure of the DVR MPEG-2 transport stream defined 
as described above. The Bridge-Clip AV stream must include discontinuous 
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point of one arrival time base. The transport stream before and after the 
discontinuous point of the arrival time base must be in conformity with the 
limitation of encoding which will be explained later and also must be in 
conformity with the DVR-STD which will be explained later. 
[0264] 

In this embodiment, seamless connection of the video and audio 
between Playltems in editing is supported. This seamless connection 
between the Playltems guarantees the player/recorder to realize the 
continuous data supply" and "seamless decoding'' . The "continuous supply 
of data" means that the file system can guarantee the decoder to supply data 
at a necessary bitrate in order that underflow of buffer does not take place. 
In order to guarantee real-time characteristic of data to have ability to read out 
data from the disc, tata are stored in units of successive blocks having 
sufficient size. 
[0265] 

The " seamless decoding means that the player can display 
audio/video data recorded on the disc without producing pause or gap in 
reproduction output of the decoder. 
[0266] 

The AV stresun that the seamlessly connected Playltem refers will be 
explained. Whether or not the connection between the previous Playltem 
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and the current Playltem is guaranteed so as to permit seamless display can 
be judged from the connection_condition field defined in the current Playltem. 
As a method for seamless connection between Playltems, there are a method 
using Bridge-Clip and a method without using Bridge-Clip. 
[0267] 

Fig. 8 8 shows the relation ship between the previous Playltem and the 
current Playltem in the case where Bridge-Clip is used. In Fig. 88, stream 
data that the player reads out is indicated in the shaded state. The TSI shown 
in Fig. 88 consists of shaded stream data of Clipl (Clip AV stream) and 
shaded stream data previous to RSPN_arrival__time_discontinuity of 
Bridge-Clip. 
[0268] 

The shaded stream data of Clipl of TSI is stream data from an address 
of a stream necessary for decoding a presentation unit corresponding to 
IN time of the previous Playltem (shown at IN time in Fig. 88) up to a source 
packet referred by RSPN_exit__fromj)revious_Clip. The shaded stream data 
previous to RSPN arrival time discontinuity of Bridge-Clip included in TSI 
is stream data from the first source packet of Bridge-Clip to a source packet 
immediately before source packets referred by 

RSPN_arrival time discontinuity. 
[0269] 

100 



On the other hand, TS2 in Fig. 8 8 consists of shaded stream data of 
Clip2 (Clip AV stream) and shaded stream data subsequent to 
RSPN_arrival_time_discontinuity of Bridge-Clip. The shaded stream data 
subsequent to RSPN_arrival_tune_discontinuity of Bridge-Clip included in 
TS2 is stream data from the source packet referred by 
RSPN_arrival__time_discontinutity up to the last source packet of Bridge_Clip. 
The stored stream data of Clip 2 of TS2 us stream data from source packet 
referred by RSPN_enter_to_current__Clip to an address of a stream necessary 
for decoding the presentation imit corresponding to OUT__time of the current 
Playltem (shown at OUT_time2 in Fig.88). 
[0270] 

Fig. 89 shows the relationship between the previous Playltem and the 
current Playltem in the case where Bridge-Clip is not used. In this case, the 
stream data that the player reads out is shown in the shaded state. The TSI in 
Fig. 89 consists of shared stream data of Clip 1 (Cli AV stream). The shared 
stream data of TSI is data beginning from the address of a stream necessary 
for decoding the presentation unit corresponding to D^^time of previous 
Playltem (shown at IN^timel in Fig. 89) and up to the last source packet of 
Clipl. On the other hand, TS2 in Fig. 89 consists of shaded stream data of 
Clip2 (Clip AV stream). 
[0271] 
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The shaded stream data of CUp2 of TS2 is stream data beginning from 
a first source packet of Clip2 and up to an address of a stream necessary for 
decoding the presentation unit corresponding to the OUT_time of the current 
Playltem (shown at OUTjime2 in Fig.89). 
[0272] 

In Figs.88 and 89, TSl and TS2 are continuous streams of source 
packets. Let now consider stream prescriptions of TSl and TS2 and 
connection conditions therebetween. As a limitation of the encoding 
structure of the transport stream, the number of video streams included in TSl 
and TS2 must be 1 . The number of audio streams included in TS 1 and TS2 
must be 2 or less. The numbers of audio streams included ^in TSl and TS2 
must be equal to each other. It is noted that an elementary stream or a 
private stream except for the above may be included in TSl and/or TS2. 
[0273] 

The limitation of video bitstream will now be explained. Fig.90 is a 
view showing an instance of seamless connection shown in the picture display 
sequence. In order that video stream can be displayed seamlessly at 
connectyion point, unnecessary pictures displayed after OUT_time 
(OUT^time of Clipl) and before the IN_time2 (IN__time of Clip2) must be 
removed by a process of re-encoding a partial stream of the Clip in the 
vicinity of the connection point. 
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[0274] 

An example of realizing seamless connection by using 
BridgeSequence in such cases as shown in Fig.90 is shown in Fig. 91. The 
video stream of Bridge-Clip previous to RSPN_arrival_time_discontinuity 
consists of encoded video streams up to the picture corresponding to the 
OUT timel of Clipl of Fig.90. Further, that video stream is connected to 
the video stream of the previous Clipl and is re-encoded so that there results 
one continuous elementary stream in conformity with the MPEG2 standard. 
[0275] 

In a manner similar to the above, the video stream of Bridge-Clip 
subsequent to RSPN_arrival time_discontinuity consists of an encoded video 
stream subsequent to a picture corresponding to IN_time2 of Clip2 of Fig.90. 
Further, that video stream is re-encoded so that decoding can be correctly 
made, and it is connected to the video stream of the Clip2 subsequent thereto 
so that there results one continuous elementary stream in conformity with the 
MPEG2 standard. For creating Bridge-Clip, several pictures must be, in 
general re-encoded, while pictures except for them can be copied from the 
original clip. 
[0276] 

An example of realizing seamless connection without using 
BridgeSequence in the case of the example shown in Fig.90 is shown in Fig. 

103 



92. The video stream of Clipl consists of an encoded video stream up to a 
picture corresponding to OUT_timel of Fig.90, this and that video stream is 
re-encoded so that there results one continuous elementary stream in 
conformity with the MPEG2 standard. Similarly, the video stream of Clip2 
consists of an encoded video stream subsequent to the picture corresponding 
to the IN-time2 of Clip2 of Fig.90, and that stream is re-encoded so that there 
results one continuous elementary stream in conformity with the MPEG2 
standard. 
[0277] 

The encoding limitation of the video stream will be explained. First, 
the frame rates of video streams of TSl and TS2 must be equal to each other. 
The TSl video stream must be terminated at sequence_end_code. The video 
stream of TS2 must be started at sequence header, GOP Header and I-picture. 
The video stream of TS2 must begins at closed GOP. 
[0278] 

The video presentation unit (frame or field) defined in a bitstream 
must be continuous with a connection point being put therebetween. It is 
prohibited that gap of frame or field exists at the connection point. At the 
connection point, field sequence of the top/bottom must be continuous. In 
the case of encoding employing the 3-2 pulldown, it may be necessary to 
rewrite "top_field_first" and *'repeat_first_field" flag, or local re-encoding 
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may also be made so as to prevent occurrence of field gap. 
[0279] 

The encoding limitations of an audio bitstream will be explained. 
Audio sampling frequencies of TS 1 and that of TS2 must be the same. The 
audio encoding methods of TSl and TS2 ,e.g., MPEGl layer 2, AC-3, SESF, 
LPCM and AAC must be the same. 
[0280] 

The encoding limitation of the MPEG-2 transport stream will now be 
explained. The last audio frame of the TSl' audio stream must includes an 
audio sample having a display time equal to display end time of the last 
display picture of TSl. The first audio frame of TS2 audio stream must 
includes an audio sample having a display time equal to that at display start 
time of the first display picture of TS2. 
[0281] 

At the connection point, there must not exist any gap in the sequence 
of the audio presentation unit. As shown in Fig. 93, there may be an overlap 
defined by the length of the audio presentation unit which is less than two 
audio frame period. The first packet for performing transmission of the 
elementary stream of TS2 must be video packet. The transport stream at the 
connection point must be in conformity with the DVR-STD which will be 
described later. 
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[0282] 

The limitations of Clip and Bridge-Clip will be explained. TSl and 
TS2 must not include discontinuous points of the arrival time bases in 
respective TSl and TS2. 
[0283] 

The following limitations are applied only in the case where 
Bridge-Clip is used. The Bridge_Clip AV stream has discontinuous point of 
only one arrival time base only at the connection point between the last source 
packet of TSl and the first source packet of TS2. The 
RSPN_arrivaMime_discontinuity defined in ClipInfo() must indicate an 
address of its discontinuous point, and it must indicate the address which 
refers the first source packet of TS2. 
[0284] 

The source packet referred by the RSPN_exit_from_previous__Clip 
defined in BridgeSequencelnfoQ may be any source packet in the Clip. It is 
unnecessary that this source packet is the boundary of the Aligned unit. The 
source packet referred by the RSPN enter to current Clip defined in 
BridgeSequencelnfoO may be any source packet in the Clip 2. It is 
unnecessary that such source packet is the boundary of the Aligned unit. 
[0285] 

The limitations on the Playltem will be explained. The OUT_time of 
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previous Playltem (OUT_time 1 shown in Figs. 8 8 and 89) must indicate the 
display end time of the last video presentation unit of TSl. The IN time of 
the current Playltem (IN_time2 shown in Figs-88 and 89) must indicate the 
display start time of the first video presentation unit of TS2. 
[0286] 

The limitations on data allocation in the case where the Bridge-Clip is 
used will be explained with reference to Fig. 102. The seamless connection 
must be created such as that continuous data supply guaranteed by the file 
system. This must be performed by disposing or assigning the Bridge-Clip AV 
stream, connected to the Clipl (Clip AV stream file) and Clip2 (Clip AV 
stream file) so as to satisfy the data allocation prescriptions. 
[0287] 

The RSPN_exit_from_previous_Clip must be selected so that the 
stream portion of the Clipl (Clip AV stream file) previous to 
RSPN_exit_from_previous_Clip (Clip AV stream file) is disposed or assigned 
within a continuous area havinghalf fragment or more. The data length of the 
Bridge-Clip AV stream must be selected so that the stream is disposed or 
assigned within a continuous area having half fragment or more. 
RSPN__enter_to_current_Clip must be selected so that the stream portion of 
Clip2 (Clip AV stream file) subsequent to RSPN_enter_to_current_Clip is 
disposed or assigned within a continuous area havinghalf fragment or more. 
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[0288] 

The limitations on data allocation in the case where seamless 
connection is made without using Bridge-Clip will be explained. The seamless 
connection must be created so that continuous data supply is guaranteed by 
the file system. This must be carried out by disposing or assigning the first 
portion of last portion of the Clipl (Clip AV stream file) and the first portion 
of the Clip2 (Clip AV stream file) so as to satisfy the data allocation 
prescriptions. 
[0289] 

The last stream portion of Clipl (Clip AV stream file) must be 
disposed or assigned within a continuous are having half fragment or more. 
The first stream portion of Clip2 (AV stream file) must be disposed or 
assigned within a continuous area having half fragment or more. 
[0290] 

The DVR-STD will now be explained. The DVR-STD is a 
conceptual model for modeling the decode processing in generation and 
verification of the DVR MPEG-2 transport stream. Moreover, the 
DVR-STD is also a conceptual model for modeling the decode processing in 
generation and verification of the AV stream refereed by the above-described 
seamless-connected two Playltems. 
[0291] 
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The DVR-STD model is shown in Fig. 96, In the model shown in 
Fig.96, there is included, as a component, a DVR MPEG-2 transport stream 
player model. The notations of n, Tbn, Mbn, Ebn, Tbsys, Bsys, Rxn, Rbxn, 
Rxsys, Dn, Dsys, On and Pn(k) are the same as those defined in T-STD of the 
ISO/IEC 138 188-1. Namely, the following description is provided, n is index 
number of elementary stream and Tbn is transport buffer of an elementary 
stream n. 
[0292] 

Mbn is a multiplex buffer of the elementary stream n, and exists only 
with respect to video stream. EBn is an elementary stream buffer in the. 
elementary stream n. It exists only with respect to the video stream. TBsys 
is an input buffer for system information of program being decoded. Bsys is 
a main buffer within a system target decoder for the system information for a 
program being decoded. Rxn is transmission rate at which data is removed 
from TBn. Rbxn is transmission rate at which data is removed from MBn. It 
exists only with respect to video stream. 
[0293] 

Rxsys is transmission rate with which data is removed from TBsys. 
Dn is a decoder of elementary stream n. Dsys is s decoder relating to the 
system information of a program being decoded. On is a re-ordering buffer 
of the video stream n. Pn(k) is the k-th presentation unit of the elementary 
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stream n. 
[0294] 

The decoding process of the DVR-STD will be explained. For a time 
during which a single DVR MPEG-2 transport stream is reproduced, the 
timing at which the transport packet is inputted to the buffer of TBn or TBsys 
is determined by the arrival_time_stamp of the source packet. The 
prescriptions of buffering operations of TBI, MBl, EBl, TBn, Bn, TBsys and 
Bsys are the same as that of T-STD prescribed in the ISO/IEC B818-1. The 
prescriptions for the decoding operation and the display operation are the 
same as that of T-STD prescribed in ISO/IEC 13818-1. 
[0295] 

The decoding process for a time period during which the 
seamless-connected Playltem is reproduced will be explained. Here, 
reproduction or playback of two AV streams, which is referred by the 
seamless_connected Playltem, will be explained. In the following 
explanation, the reproduction or playback of the above-described TSl And 
TS2, (e.g., shown in Fig.88) will be explained. TSl and TS2 are a previous 
stream and a current stream, respectively. 
[0296] 

Fig.97 shows a timing chart of inputting, decode and display of 
transport packet when shift from a certain AV stream (TSl) to the subsequent 
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AV stream (TS2) seamlessly comiected thereto is performed. For a time 
period during which shift from a predetermined AV stream (TSl) to the 
subsequent AV stream (TS2) comiected seamlessly thereto is performed, the 
time axis of the arrival time base of TS2 (indicated at STC2 in Fig.97) is not 
the same as the time axis of the arrival time base of TSl (indicated at STCl 
in Fig.97). 
[0297] 

Moreover, the time axis of the system time base of TS2 (indicated at 
STC2 in Fig.97) is not the same as the time axis of the system time base of 
TSl (indicated at STCl in Fig.97). Video display is required to be 
seamlessly continued. There there may be overlap in the display time of the 
audio presentation imit. 
[0298] 

The input timing to the DVR-STD will be explained. Until the time 
Tl, i.e., the time at which the last video packet of TSl is completely inputted 
to the TBI of DVR-STD, the input timing to the buffer of TBI, TBn or TBsys 
of DVR-STD is determined by the arrival_time_stamp of the source packet of 
TSl. 
[0299] 

The remaining packet of TSl must be inputted to the buffer of TBn or 
TBsys at a bitrate of TS_recording_rate (TSl), where TS_recording_rate 
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(TSl) is a value of the TS_recording_rate defined in the CHpInfoQ 
corresponding to the Clipl. The time at which the last byte of TSl is 
inputted to the buffer is the time T2. Accordingly, in the time period from 
time Ti up to time T2, arrival_time_stamp of the source packet is disregarded. 
[0300] 

If Nl is the number of bytes of the transport packet of TSl subsequent 
to the last video packet of TSl, the time DTI from time Ti up to time T2 is a 
time required until input of Nl bytes is completed at a bitrate of 
TS recording rate (TSl), and is calculated in accordance with the following 
equation: 

DT1=T2 - Ti =Nl/TS_recording__^rate(TSl). 

For a time period from the time TI up to the time T2, values of RXn 
and RXsys are both changed into the value of TS recording_rate (TSl). The 
buffering operation except for this rule is the same as that of the T-STD. 
[0301] 

At time T2, the arrival time clock counter is reset to the value of 
arrival time stamp of the first source packet of TS2. The input timing to the 
input timing of the TBI, TBn or TBsys is determined by the 
arrival_time_stamp of the source packet of TS2. The Rxn and Rxsys are 
both changed into values defined in T-STD. 
[0302] 
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The additional audio buffering and the system data buffering will be 
explained. The audio decoder and the system decoder are required to have 
an additional buffer quantity (data quantity corresponding to about one 
second) in addition to the buffer volume defined in T-STD. 
[0303] 

The video presentation timing of video will be explained. The 
display of the video presentation unit must be continuous, via the connection 
point, without gap. It is assumed that STCl is the time axis of the TSl 
system time base (shown at STCl in Fig.97), and STC2 is the time axis of the 
TS2 system time base (shown at STC2 in Fig.97). More precisely, STC2 
begins from the time at which the first PGR of TS2 is inputted to T-STD. 
[0304] 

The offset between STCl and STC2 is determined as follows. When 
it is assumed that PTS'end is PTS on STCl corresponding to the last video 
presentation unit of TSl, PTS^stan is PTS on STC2 corresponding to the first 
video presentation unit of TS2, and Tpp is the display period of the last video 
presentation unit of TSl, the offset STC_delta between two system time bases 
can be calculated in accordance with the following equation: 

STC_delta = PTS'e„d + Tpp - PTS^tart 

[0305] 

. The timing of the audio presentation will be explained. There may 
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exist any overlap of display timing of audio presentation unit at the connection 
point, and it is zero to 2 audio frames or less (see "audio overlap" shown in 
Fig,97). Which audio sample should be selected and re-synchronization of 
the display of the audio presentation unit to corrected time base after the 
connection point are set by the player side. 
[0306] 

The system time clocks of DVR-STD will be explained. The last 
audio presentation unit of TSl is displayed at time T5. The system time 
clocks may overlap with each other between time T2 and time T5. For this 
time period, in the DVR-STD, system time clock is switched between the old 
time base value (STCl) and the new time base value (STC2). The value of 
STC2 can be calculated in accordance with the following equation: 

STC2 = STC1 - STC_delta. 

[0307] 

The buffering continuity will be explained. STC'video_end is the value of 
STC on the system time base STCl when the last byte of the last video packet 
of TSl reaches TBI of DVR-STD. STC^ video-start is a value of STC on 
system time base when the first byte of the first video packet of TS2 reaches 
TBI of DVR-SFD. STC2^video_end is a value converted into a value on the 
system time base STC2. The STC2^video_end is calculated by the following 
equation: 
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STC2 ^ video_end STC 1 ^ video_end STC_delta, 

[0308] 

In order to become in conformity with the DVR-STD, it is required to 
satisfy the following two conditions. First, the arrival timing to TBI of first 
video packet of TS2 must satisfy the following inequality: 

STC2 video_slart ^ STC2 video_end . 

In the case where there is a necessity to re-encode or re-multiplex 
partial stream of Clip 1 and/or Clip 2 in order that the above-mentioned 
inequality is satisfied, such operation is performed as occasion demands. 
[0309] 

Then, on the time axis of the system time base in which STCl and 
STC2 are converted onto the same time axis, input of video packet from TSl 
and input of video packet from TS2 subsequent thereto is prohibited to allow 
the video buffer to overflow or underflow. 
[0310] 

On the basis of such syntax, data structure and rule, it is possible to 
suitably perform management of the content of data recorded on the recording 
medium and/or reproduction information . Thus, user can suitably confirm 
the content of data recorded on the recording medium at the time of 
reproduction or playback, on or to reproduce desired data with ease. 
[0311] 
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While the above-described sequence of operations can be executed by 
hardware, they may be also executed by software. In the case where a 
sequence of processing is caused to be performed by the software, programs 
constituting the software are installed from a recording pedium into a 
computer in which those programs are assembled in a dedicated hardware, 
and/or, e.g., general-purpose personal computer in which various programs are 
installed to thereby have ability to execute various fimctions, etc. 
[0312] 

As shown in Fig.98, this recording medium not only may be 
constituted by a package medium comprised of a magnetic disc 221 (including 
of floppy disc), an optical disc 222 (including CD-ROM (Compact Disc- 
Read Only memory) and DVD (Digital versatile Disc)), a magneto-optical 
disc 223 (including MD (Mini-Disc)) and or a semiconductor memory 224, 
etc. where programs are recorded, which is distributed for the purpose of 
offering program to user, but also may be constituted by a hard disc, etc. in 
which a ROM 202 or a memory 208 having program stored therein, which is 
offered to user in the state assembled into the computer in advance. 
[0313] 

In this specification, steps which describe the program offered by a 
medium includes not only the processing executed in time series manner in 
accordance with the described order, but also includes processing executed in 
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parallel or individually even if they are not necessarily processed in time 
series manner. 

[0314] ^ 

In addition, in this specification, the system represents the entirety of 
an apparatus composed of plural devices. 
[0315] 

[Advantages/Effects of the invention] 

As described above, in accordance with the information processing 
apparatus according to claim 1 , the information processing method according 
to claim 3 and the recording medium according to claim 4, since AV stream 
which has been recorded from the time point where recording of AV stream 
has been started up to the time point where it is completed is caused to be one 
unit to record, onto or into recording medium, at least one of information 
relating to recording mode of AV stream, information relating to average 
value of recording rate of the AV stream, information relating to the period 
where encoded information is the same of the AV stream, information relating 
to random accessible position in the AV stream and informating relating to 
featured image in the AV stream as attribute information of the AV stream, on 
the unit basis, such information may be used, thereby making it possible to 
rapidly perform determination of readout position and/or decode processing of 
AV stream. 
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[Brief Description of the Drawings] 

Fig. 1 is a view showing the configuration of an embodiment of a 
recording/reproducing apparatus to which the present invention is appUed. 

Fig. 2 is a view for explaining the format of data recorded on a 
recording medium by the recording/reproducing apparatus 1 . 

Fig. 3 is a view for explaining Real PlayList £ind Virtual PlayList. 

Fig. 4 is a view for explainign the creation of the Real PlayList. 

Fig. 5 is a view for explaining deletion of the Real PlayList. 

Fig. 6 is a view for explaining assemble editing. 

Fig. 7 is a view for explaining the case where sub path is provided in 
the Virtual PlayList. 

Fig. 8 is a view for explaining change of the playback order of the 
PlayList. 

Fig. 9 is a view for explaining mark on the PlayList and mark on the 

Clip. 

Fig. 10 is a view for explaining menu thumbnail. 
Fig. 1 1 is a view for explaining mark added to the PlayList. 
Fig, 12 is a view for explaining mark added to the Clip. 
Fig. 13 is a view for explaining the relationship between the PlayList, 
Clip and the thumbnail file. 

Fig. 14 is a view for explaining directory structure. 
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Fig. 15 is a view showing syntax of infr.dvn 
Fig. 16 is a view showing syntax of DVR volume- 
Fig. 17 is a view showing syntax of ResumeVolume. 
Fig. 18 is a view showing syntax of UIAppInfo Volume. 
Fig. 1 9 is a view showing table of Character set value. 
Fig. 20 is a view showing syntax of TableOfPlayList. 
Fig. 21 is a view showing another syntax of TableOfPlayList. 
Fig. 22 is a view showing syntax of the MakersPricvateData. 
Fig. 23 is a view showing syntax of xxxx.rpls and yyyyy-vpls. 
Fig. 24 is a view for explaining the PlayList. 
Fig. 25 is a view showing syntax of PlayList. 
Fig. 26 is a view showing table of PlayList type. 
Fig. 27 is a view showing syntax of UIAppInfoPlayList. 
Fig. 28 is a view for explaining flags in the syntax of the 
IHAppInfoPlayList shown in Fig. 27. 

Fig. 29 is a view for explaining Playltem. 
Fig. 30 is a view for explaining Playltem. 
Fig. 31 is a view for explaining Playltem, 
Fig. 32 is a view showing syntax of the Playltem. 
, Fig. 33 is a view for explaining IN_time. 
Fig. 34 is a view for explaining OUT_time. 
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Fig, 35 is a view showing table of Connection Condition. 

Fig. 36 is a view for explaining Connection Condition. 

Fig. 37 is a view for explaining BridgeSequencelnfo. 

Fig. 38 is a view showing syntax of BridgeSequencelnfo. 

Fig. 39 is a view for explaining SubPlayltem. 

Fig. 40 is a view showing syntax of SubPlayltem. 

Fig. 41 is a view showing table of SubPath_type. 

Fig. 42 is a view showing syntax of PlayListMark. 

Fig. 43 is a view showing table of Mark_type. 

Fig. 44 is a view for explaining Mark_time_stamp. 

Fig. 45 is a view showing syntax of zzzzz.clip. 

Fig. 46 is a view showing syntax of Cliplnfo. 

Fig. 47 is a view showing table of Clip_stream_type. 

Fig. 48 is a view for explainmg ofiFset_SPN. 

Fig. 49 is a view for explaining ofiFset_SPN. 

Fig. 50 is a view for explaining the STC period. 

Fig. 5 1 is a view for explaining STC Info. 

Fig. 52 is a view showing syntax of STC_Info. 

Fig. 53 is a view for explaining Programlnfo. 

Fig. 54 is a view showing syntax of Programlnfo. 

Fig. 55 is a view showing syntax of VideoCondinglnfo. 
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Fig. 56 is a view showing table of Video_format. 

Fig. 57 is a view showing table of frame rate. 

Fig. 58 is a view showing table of display aspect ratio. 

Fig. 59 is a view showing syntax of AudioCondinglnfo. 

Fig. 60 is a view showing table of audio coding. 

Fig. 61 is a view showing table of audio_component_type. 

Fig, 62 is a view showing table of sampling_frequency. 

Fig. 63 is a view for explaining CPL 

Fig. 64 is a view for explaining CPI. 

Fig. 65 is a view showing syntax of CPI. 

Fig. 66 is a view showing table of CPI_type. 

Fig. 67 is a view for explaining video EP__map. 

Fig. 68 is a view for explaining EP_map. 

Fig. 69 is a view for explaining EP_map. 

Fig. 70 is a view showing syntax of EP_map. 

Fig. 71 is a view showing table of EP type values. 

Fig. 72 is a view showing syntax of EP map for_one stream PID. 

Fig. 73 is a view for explaining TU_map. 

Fig. 74 is a view showing syntax of TU_map. 

Fig. 75 is a view showing syntax of ClipMark. 

Fig. 76 is a view showing table of mark_type. 
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Fig, 77 is a view showing table of mark_type_stamp. 

Fig. 78 is a view showing syntax of menu.thmb and mark.thmb. 

Fig- 79 is a view showing syntax of Thumbnail. 

Fig. 80 is a view showing table of thumbnail_picture_format. 

Fig. 81 is a view for explaining tn block. 

Fig. 82 is a view for explaining the structure of a transport stream of 
DVR MPEG2. 

Fig. 83 is a view showing recorder model of the transport stream of 
DVRMPEG2. 

Fig. 84 is a view showing player model of the transport stream of 
DVRMPEG2. 

Fig. 85 is a view showing syntax of source packet. 
Fig. 86 is a view showing syntax of TP extra_header. 
Fig. 87 is a view showing table of copy permission indicator. 
Fig. 88 is a view for explaining seamless connection. 
Fig. 89 is a view for explaining seamless connection. 
Fig. 90 is a view for explaining seamless connection. 
Fig. 91 is a view for explaining seamless connection. 
Fig. 92 is a view for explaining seamless connection. 
Fig. 93 is a view for explaining overlap of audio. 

Fig. 94 is a view for explaining seamless connection using 
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BridgeSequence. 

Fig. 95 is a view for explaining seamless connection without using 
BridgeSequence. 

Fig. 96 is a view showing DVR STD model. 

Fig. 97 is a view showing a timing chart for decoding and display. 

Fig. 98 is a view for explaining medium. 
[Explanation of referenced numbers] 

1 Recording/Reproducing Apparatus, 11 to 13 Terminal, 14 Analysis Unit, 15 
AV Encoder, 16 Multiplexer, 17 Switch, 18 Multiplexed Stream Analysis Unit, 
19 Source Packetizer, 20 ECC Unit, 21 Modulation Unit, 22 Write Unit, 23 
Controller, 24 User Interface, 25 Switch, 26 Demuhiplexer, 27 AV Decoder, 
28 Readout Unit, 29 Demodulation Unit, 30 ECC Decoding Unit, 31 Source 
Packetizer, 32, 33 Terminal 
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SYNTAX 


No. of 
bits 


Mnemonics 


info.dvr { 






TabIeOfPIayLists_Start_address 


32 


uimsbf 


MakersPrivateData_Start_address 


32 


uimsbf 


reserved 


192 


bslbf 


DVRVolumeO 






for (i=0;i<Nl;i++){ 






paddiiig_word 


16 


bslbf 


} 






TableOfPIayListsO 






. for (i=0;i<N2;i++){ 






padding_word 


16 


bslbf 


} 






MakersPrivateDataQ 






} 







Syntax of infr.dvr 
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SYNTAX 


No. of 
bits 


Mnemonics 


DVRVolumeOi 






version_number 


8*4 


bslbf 


length 


32 


uimsbf 


ResumeVoliuneO 






UIAppInfoVolumeO 






} 







Syntax of DVRVolume 
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SYNTAX 


No. of 
bits 


Mnemon i cs 


ResumeVolume 0 i 






reserved 


15 


bslbf 


valid_flag 


1 


bslbf 


resiinie_PlayList_naine 


8*10 


bslbf 


} 







Syntax of ResumeVolume 
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SYNTAX 


No. of 
bits 


Mnemonics 


UIAppInfoVolume 0 { 






character_set 


8 


bslbf 


name_Iength 


8 


uimsbf 


Yolume.name 


8*256 


bslbf 


reserved 


15 


bslbf 


Volumejprotect.flag 


1 


bslbf 


PIN 


8*4 


bslbf 


ref_thumbnail_mdex 


16 


uimsbf 


reservedJFor_future_use 


256 


bslbf 


) 







Syntax of UIAppInfoVolume 
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VALUE 


CHARACTER LETTER ENCODING 


0x00 
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0x01 


ISO/IEC 646 (ASCII) 


0x02 


ISO/IEC 10646-1 (Unicode) 


0x03-0xflf 


Reserved 



Character set values 
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SYNTAX 


No. of 
bits 


Mnemonics 


TableOfPlaylistsOl 






version^number 


8*4 


bslbf 


length 


32 


uimsbf 


number__of_PIayLists 


16 


uimsbf 


for (i=0; i<number_ofJPlayLists\ i++){ 






PlayList_fae_name 


8*10 


bslbf 








} 







Syntax of TableOfPlayList 
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TableOfPlayLists - syntax (another example of 4.2.3.2) 



SYNTAX 


No. of 
bits 


Mnemon i cs 


TableOfPlay Lists 0{ 






▼ersion_number 


8*4 


bslbf 


length 


32 


uimsbf 


number_of_PIayLists 


16 


uimsbf 


for ii=0; i<number_of_PlayLists; i++){ 






PlayList_file_name 


8*10 


bslbf 


UIAppInfoPlayListO 






} 






} 







Another syntax of TableOfPlayLists 
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SYNTAX 


No. of 
bi ts 


Mnemon i cs 


MakersPrivateDataO { 






version_number 


8*4 


bslbf 


length 


32 


uimsbf 


if Oength !=0){ 






mpd_block5_5tart_address 


32 


uimsbf 


number_of_maker_entries 


16 


uimsbf 


mpd_Wock_size 


16 


uimsbf 


number_of_mpd_:blocks 


16 


uimsbf 


reserved 


16 


bslbf 


for (i=0; \<number_of_maker_entries\ i++) { 






inaker_EO 


16 


uimsbf 


inaker_model„code 


16 


uimsbf 


start„inpd_block_niimber 


16 


uimsbf 


reserved 


16 


bslbf 


mpd Jength 


32 


uimsbf 


} 






stuffing_bytes 


8*2*L1 


bslbf 


for(j=0; }<number_of_mpdJblocks; j++) { 






inpd_block 


mpd_block^ 
size*1024*8 




} 






} 






} 







Syntax of MakersPrivateData 
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SYNTAX 


No. of 
bits 


Mnemon i cs 


xxxxx.rpls / yyyyy.vpls { 






PIayLi5tMark_Start_address 


32 


uimsbf 


MakersPriyateData_Start_address 


32 


uimsbf 


reserved 


192 


bslbf 


PlayListO 






for a=0;i<Nl;i++){ 






padding_word 


16 


bslbf 


} 






PlayListMarkO 






for (i=0;i<N2;i++){ 






padding_word 


16 


bslbf 


} 






MakersFriyateDataQ 






} 







Syntax of xxxx.rpis and yyyy.vpis 
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CUp 



Real PlayUst when AV stream is firstly recorded as Clip 



(B) 



Real Playlist 



T 1 



Clip 



Real Play 
List 


Real Playlist 


Real Playlist 






r 1 


f 


» 

■■ 




CUp 1 


CUp 


CUp ] 



Real PlayUst after editing operation 
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Virtual PlayList 
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SYNTAX 


No. of 
bits 


Mnemonics 


PlayUstOi 






version_nuniber 


8*4 


bslbf 


length 


32 


uimsbf 


PlayLlst_type 


8 


uimsbf 


CPI_type 


1 


bslbf 


reserved 


7 


bslbf 


UIAppInfoPlayListO 






number.of JPIayltems // main path 


16 


uimsbf 


if i<Vertual PlayList>) { 






nuinber_of_SubPlayItenis // sub path 


16 


uimsbf 


}else{ 






reserved 


16 


bslbf 


} 






for (piayltemjd=0; 

PlayItem_id<nymber_ofJPlayItems; 
PlayIt€m_id++){ 






PlayltemQ //main path 






} 






if {<Virtual PlayList>) { 






if (CPI_type==0 && Playlist_type==0) { 






for 0=0; \<number_of _SubPlayItems; i++) 






SubPIayltemO //sub path 






} 






} 






} 







Syntax of PlayList 
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PlayDst_type 


MEANING 


0 


PlAY LIST FOR AV RECORDING 

ALL CLIPS REFERENCED IN THIS PLAY UST MUST 
CONTAIN ONE OR MORE VIDEO STREAMS 


1 


PLAY UST FOR AUDIO RECORDING 

ALL CUPS REFERENCED IN THIS PLAYUST MUST 
CONTAIN ONE OR MORE AUDIO STREAMS AND MUST 
NOT CONTAIN VIDEO STREAMS 


2-255 


reserved 



PlayList_type 
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SYNTAX 


No. of 
bits 


Mnemonics 


UIAppInfoPlayList2 0 { 






character.set 


8 


bslbf 


name.length 


8 


uiihsbf 


PlayList.name 


8*256 


bslbf 


reserved 


8 


bslbf 


record_time_and_date 


4*14 


bslbf 


reserved 


8 


bslbf 


duration 


4*6 


bslbf 


valid^period 


4*8 


bslbf 


maker.id 


16 


uimsbf 


maker.code 


16 


uimsbf 


reserved 


11 


bslbf 


playback_controI_flag 


1 


bslbf 


vn*ite_protect_flag 


1 


bslbf 


is_played_flag 


1 


bslbf 


archive 


2 


bslbf 


ref_tliumbnail_index 


16 


uimsbf 


reserved_for_future_use 


256 


bslbf 


} 







Syntax of UIAppInfoPlayList 
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(A) 



write_protect_flag 


MEANING 


Ob 


THE PlayList CAN BE ERASED FREELY 


lb 


THE PlayUst CONTENTS SHOULD NOT BE ERASED 
NOR CHANGED EXCEPT write-protect-flag 




write_protect_flag 


(B) 




is_played_flag 


MEANING 


Ob . 


THE PlayUst HAS NOT BEEN REPRODUCED SINCE 
rrS RECORDING 


lb 


THE Playlist WAS ONCE REPRODUCED SINCE ITS 
RECORDING 


(C) 


is_played_flag 


archive 


MEANING 


00b 


NO MEANING DEFINED 


01b 


ORIGINAL 


10b 


COPY 


lib 


reserved 



archive 
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SYNTAX 


No. of 
bits 


Mnemonics 


PlayltemOl 






Clip_information_fiIejname 


8*10 


bslbf 


reserved 


24 


bslbf 


STC_sequence_id 


8 


uimsbf 


IN_time 


32 


uimsbf 


OUT_tiine 


32 


uimsbf 


reserved 


14 


bslbf 


connection_condifion 


2 


bslbf 


if (<VirtualPlayList>){ 






if ((connection_condition=='10^[ 






Bridg^equencelnfoO 






} 






} 






} 







Syntax of Playltem 



[FIG.33] 



CPI_type 

in the PlayListQ 


SEMANTICS OF IN_time 


EP_map type 


IN.time MUST INDICATE UPPER 32 BITS OF 33 BIT 
LENGTH CORRESPONDING TO FIRST PRESENTATION 
UNTTINPlayltem 


TU_map type 


IN_time MUST BE TIME ON TU_map_time_axis, AND 
MUST BE ROUNDED TO time_unit PRECISION. IN-time IS 
CALCULATED BY FOLLOWING EQUATION: 

IN_time = TU_start_time %2^^ 



IN-time 



[FIG.34] 



CPI_type 

in the PlayUstO 


SEMANTICS OF OUT_time 


EP_map lype 


OUT_time MUST INDICATE UPPER 32 BITS OF THE 
VALUE OF Presentation_end_TS CALCULATED BY 
FOLLOWING EQUnON: 

Presentation_end_TS = PTS_out+AU_duration 

WHERE PTS_out IS 33-Brr LONG PTS CORRESPONDING 
TO LAST PRESENTATION UNIT IN Playltem. AU_duration 
IS 90 kHz-DISPLAYTIME OF LAST PRESENTATION UNIT. 


TU_map type 


OUT_time MUST BE TIME ON TU_map_time_axis AND BE 
ROUNDED TO time_unit PRECISION. OUT_time IS 
CALCULATED BY FOLLOWING EQUATION: 

OUT_time = TU_start_time %2^ 



OUT-time 
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connection 
.condition 


MEANING 


00 


• CONNECTION OF PREVIOUS Playltem TO CURRENT 
Playltem IS NOT SURE AS TO SEAMLESS REPLAY. 

• IF CPLtype OF PlayList IS TU_map type, THIS VALUE MUST 
BE SET IN connection_condition. 


01 


• THIS STATE IS ALLOWED ONLY WHEN CPI_type OF 
PlayList IS EP_map type. 

• PREVIOUS Playltem AND CURRENT Playltem INDICATE 
DIVISION BECAUSE OF NON-CONTINUOUS POINT OF 
SYSTEM TIMEBASE (STC BASE). 


10 


• THIS STATE IS ALLOWED ONLY WHEN CPI_type OF 
PlayList IS EP_map type. 

• THIS STATE IS ALLOWED ONLY FOR Virtual PlayUst 

• CONNECTION OF PREVIOUS Playltem TO CURRENT 
Playltem IS SURE AS TO SEAMLESS REPLAY. 

• PREVIOUS Playltem IS CONNECTED TO CURRENT 
Playltem USING BridgeSequence. DVR MPEG-2 TRANSPORT 
STREAM MUST OBEY DVR-STD AS LATER DESCRIBED. 


11 


• THIS STATE IS ALLOWED ONLY WHEN CPI_type OF 
PlayUst IS EP_map type. 

• CONNECTION OF PREVIOUS Playltem TO CURRENT Play 
Item IS SURE AS TO SEAMLESS REPLAY. 

• PREVIOUS Playltem IS CONNECTED TO CURRENT 
Playltem WITHOUT USING BridgeSequence. DVR MPEG-2 
TRANSPORT STREAM MUST OBEY DVR-STD AS LATER 
DESCRIBED. 



connection_condition 
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SYNTAX 


No. of 
bits 


Mnemon 1 cs 


BridgeSequencelnfoO { 






Bridge_Clip_information_file_name 


8*10 


bslbf 


RSPN_exit_froin_j»revious_Clip 


32 


uimsbf 


RSPN_enter_to_current_Clip 


32 


uimsbf 


} 







Syntax of BridgeSequencelnfo 
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SYNTAX 


No. of 
bits 


Mnemon 1 cs 


SubPlayltemOl 






Clip_Information_file_name 


8*10 


bslbf 


SubPath_type 


8 


bslbf 


sync_PlayItein_id 


8 


uimsbf 


sync_start_PTS_of_PlayItem 


32 


uimsbf 


SubPath_JN_thne 


32 


tumsbf 


SubPath_OUT_time 


32 


uimsbf 


) 







Syntax of SubPlayltem 



SubPath_type 


MEANING 


0x00 


Auxiliary audio steam path 


OxOl-Qxff 


reserved 



SubPath_type 



[FIG.42] 



SYNTAX 


fin nt 

no. OT 
bits 


Mnemonics 


PlayUstMarkOf 






version_number 


8*4 


bslbf 


length 


32 


uimsbf 


number_of_PIayList_marks 


16 


uimsbf 


for {i-0;i<number_ofJPlayList_marks;i'^^ { 






reserved 


8 


bslbf 


mark__type 


8 


bslbf 


mark_tiine_stamp 


32 


uimsbf 


Playltem_id 


8 


uimsbf 


reserved 


24 


uimsbf 


character^set 


8 


bslbf 


namejength 


8 


uimsbf 


mark.name 


8*256 


bslbf 


ref.thumbnail.index 


16 


uimsbf 


} 






} 







Syntax of PlayListMark 



[FIG.43] 



Mark_type 


MEANING 


COMMENT 


0x00 


resume-mark 


REPIAY RESUME POINT. THE NUMBER OF 
REPLAY RESURE POINTS DEFINED IN 
PlaylistMarkO MUST BE 0 OR 1. 


0x01 


book-mark 


REPLAY ENTRY POINT OF PlayList. THIS 
MARK CAN BE SET BY USER AND USED AS 
MARK SPECIFYING START POINT OF 
FAVORITE SCENE. 


0x02 


skip-mark 


SKIP MARK POINT. PLAYER SKIPS 
PROGRAM FROM THIS POINT TO THE END 
OF PROGRAM. THE NUMBER OF SKIP 
MARK POINTS DEFINED IN PlayListMarkQ 
MUSTBEOROL 


0x03-Qx8F 


reserved 




OxSOOssFF 


reserved 


Reserved for ClipMarkO 



mark_type 



[FIG.44] 



CPI.lype 

in the PlaylistO 


SEMANTICS OF mark_time_stamp 


EP_map type 


mark_time_stamp MUST INDICATE UPPER 32 BITS OF 33 
BIT LENGTH PTS CORRESPONDING TO PRESENTATION 
UNIT REFERENCED BY MARK 


TU_map type 


mark_time_stamp MUST BE TIME ON TU_map_time_axis 
AND MUST BE ROUNDED TO time.unit PRECISION. 
mark_time_stamp IS CALCULATED BY FOLLOWING 
EQUATION: 

mark_time_stamp = TU_start_time 



mark_time_stamp 



[FIG.45] 



SYNTAX 


No. of 
bits 


Mnemonics 


zzzzz.clpi { 






STC_Info_Start_address 


32 


uimsbf 


PrograinInfo_Start_address 


32 


uimsbf 


CPI_Start_address 


32 


uimsbf 


ClipMark_Start_address 


32 


uimsbf 


MakersPrivateData_Start_address 


32 


uimsbf 


reserved 


96 


bslbf 


ClipInfoQ 






for (i=0;i<Nl;i++){ 






padding_word 


16 


bslbf 


) 






STC_InfoO 






for (i=0;i<N2;i++){ 






paddmg_word 


16 


bslbf 


) 






ProgramlnfoO 






for (i=0;i<N3;i++){ 






padding_word 


16 


bslbf 


} 






CPIO 






for Ci=0;i<N4;i-H-){ 






padding_word 


16 


bslbf 


) 






ClipMarkO 






for a=0:i<N5;i++){ 






padding_word 


16 


bslbf 


} 






MakersPriyateDataQ 






} 







Syntax of zzzzz.cipi 



[FIG.46] 



SYNTAX 


No of 
bits 


Mnemonics 


CMpInfoOf 






version.number 


8*4 


bslbf 


length 


32 


uimsbf 


CIip_streain_type 


8 


bslbf 


offset^SPN 


32 


uimsbf 


TS__recording_rate 


24 


uimsbf 


reserved 


8 


bslbf 


record_time_and_date 


4*14 


bslbf 


reserved 


8 


bslbf 


duration 


4*6 


bslbf 


reserved 


7 


bslbf 


time_controUed_flag 


1 


bslbf 


TS_average„rate 


24 


uimsbf 


if ( Clip__stream_type= =1) // Bridge-Clip AV stream 






RSPN arrival time discontinuitv 


32 


uimsbf 


else 






reserved 


32 


bslbf 


reserved_for_system_use 


144 


bslbf 


reserved 


11 


bslbf 


is_formatJdentifier__valid 


1 


bslbf 


is_original_network_ID.valid 


1 


bslbf 


is.transport_streamJDD_valid 


1 


bslbf 


is_scrvice_n)_vaMd 


1 


bslbf 


is_country_code_valid 


1 


bslbf 


format_identifier 


32 


bslbf 


original_netivork_ID 


16 


uimsbf 


transport_stream_ID 


16 


uimsbf 


service_ID 


16 


uimsbf 


country_code 


24 


bslbf 


stream_format_name 


16*8 


bslbf 


reserved_for„fortime_use 


256 


bslbf 


} . 







Syntax of Ciiplnfo 



Clip_stream_type 


MEANING 


0 


CUpAV STREAM 


1 


Bridge-Clip AV STTREAM 


2-255 


Reserved 



Clip_stream_type 



[FIG.48] 



original 
Clip 

AV stream 



FIRST SOURCE PACKET 
OF Clip AV STREAM 







1 


1 







m 



offset SPN=0 



ADDRESS OF CHp AV STOEAM 
(RELATTVE SOURCE 
PACKET NUMBER) 



ERASURE OF SOURCE 
PACKETS SHOWN SHADED 



edited 
Clip 

AV stream 



offset SPN=4 



ADDRESS OF CUp AV STREAM 
(RELATIVE SOURCE 
PACKET NUMBER) 



offset_SPN assumes value other than 0 



[FIG.49] 



Clip 

AV stream 



FIRST SOURCE PACKET 
OF CUpAV STREAM 



m 



offset SPN RSPN xxx 



ADDRESS OF CHp AV STREAM 
(RELATIVE SOURCE 
PACKET NUMBEIO 



SPN_xxx=5 

Relation between offset_SPN and relative source 
packet number (SPN_xxx) in AV stream 



[FIG.50] 
(A) 



STC 



TIME DOMAIN NOT 
CONTAINING STC 
NON-CONTINUOUS 
POINT 




o : ARRIVAL TIME OF 
LAST BYTE OF PCR IN 
TS PACKET 



ARRIVAL TIME CLOCK 



STC 



(B) 



STC=.QxlffiEfff£f 



TIME DOMAIN NOT 
CONTAINING STC 
NON-CONTINUOUS 
POINT 

src=o -- 



STC33 BIT COUNTER IS 
WRAPAROUNDED HERE 




ARRIVAL TIME CLOCK 



[FIG.51] 




[FIG.52] 



SYNTAX 


No. of 
bits 


Mnemonics 


STC_InfoO{ 






version_number 


8*4 


bslbf 


length 


32 


uimsbf 


if aength!=0){ 






reserved 


8 


bslbf 


niim_of_STC_sequences 


8 


uimsbf 


for (STC_sequence_id=0; 

STC_sequence_id<num_of_STC_5equences; 
STC_sequence_id++){ 






resereved 


32 


bslbf 


RSPN_STC_start 


32 


uimsbf 


} 






} 






} 







Syntax of STCJnfo 



[FIG.53] 
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[FIG.54] 





No. of 




SYNTAX 


bi ts 


Mnemonics 


ProgramlnfoOI 






version_number 


8*4 


bslbf 


length 


32 


uimsbf 


if aength!=0){ 






reserved 


8 


bslbf 


number_of_program_sequences 


8 


uimsbf 


for (ji=0;i<number_of_program_sequences;i++) { 






RSPN_prograin_sequence_start 


32 


uimsbf 


reserved 


48 


bslbf 


PCR_PID 


16 


bslbf 


nuinber_of_videos 


8 


uimsbf 


nuinber_of_audios 


8 


uimsbf 


for (k=Oik<number_of_videos;k++) { 






video_stream_PID 


16 


bslbf 


VideoCodinglnfoO 






} 






for (^=0;k<number_of_audios]k++) { 






audio_streain_Pn) 


16 


bslbf 


AudioCodinglnfoO 






} 






) 






) 






} 







Syntax of Programlnfo 



[F1G.55] 



SYNTAX 


No. of 
bits 


Mnemonics 


A^deoCodinglnfoO ( 






videojrormat . 


8 


uimsbf 


frame_rate 


8 


uimsbf 


djspIay_aspect_ratio 


8 


uimsbf 


reserved 


8 


bslbf 


} 







Syntax of VideoCoridinglnfo 



[FIG.56] 



video_format 


MEANING 


0 


480i 


1 


576i 


2 


480p (including 640X480p format) 


3 


lOSOi 


4 


720p 


5 


1080p 


6-254 


reserved 


255 


No information 



video_format 

[FIG.57] 



frame_rate 


MEANING 


0 


forbidden 


1 


24 000/1001 (23.976...) 


2 


24 


3 


25 


4 


30 000/1001 (29.97..) 


5 


30 


6 


50 


7 


60 000/1001 (59.94..) 


8 


60 


9-254 


reserved 


255 


No information 



frame_rate 



display_aspect_ratio 


MEANING 


0 


forbidden 


1 


reserved 


2 


4:3 display aspect ratio 


3 


16:9 display aspect ration 


4-254 


reserved 


255 


No information 



clisplay_aspect_ratio 



[RG.59] 



SYNTAX 


No. of 
bits 


Mnemon i cs 


AudioCodinglnfoO I 






audio_fonnat 


8 


uimsbf 


audio_component_type 


8 


uimsbf 


sampling_frequency 


8 


uimsbf 


reserved 


8 


bslbf 


} 







Syntax of AudioCondinglnfo 



audio_coding 


MEANING 


0 


MPEG-1 audio layer I or II 


1 


Dolby AC-3 audio 


2 


MPEG-2AAC 


3 


MPEG-2 multi-channel audio, backward 
compatible to MPEG-1 


4 


SESFLPCM audio 


5-254 


reserved 


255 


No information 



audio_cocling 



[FIG.61] 



audio_component_1ype 


MEANING 


0 


single mono channel 


1 


dual mono channel 


2 


stereo (2-channel) 


3 


multi-lingual, multi-channel 


4 


surround sound 


5 


audio description for the visually impaired 


6 


audio for the hard of hearing 


7-254 


reserved 


255 


No information 



audio_component_type 

[FIG.62] 



sampling_frequency 


MEANING 


0 


48 kHz 


1 


44.1kHz 


2 


32 kHz 


3-254 


reserved 


255 


No information 



sampling_frequency 



[FIG.63] 




[FIG.64] 




[FIG.65] 



SYNTAX 


No. of 
bits 


Mnemon i cs 


cpioi 






version_namber 


8*4 


bslbf 


length 


32 


uimsbf 


reserved 


15 


bslbf 


CPI_type 


1 


bslbf 


if (CPI_type==0) 






EP_mapO 






else 






TU_mapO 






} 







Syntax of CPI 



[FIG.66] 



CPI_type 


MEANING 


0 


EP map type 


1 


TU map type 



[FIG.67] 



CPI.type 



CHp 

AV STREAM 



pts(xl) 

pts(yl) 
pts(zl) 




I 



pts(y2) pts(yn) 

pts(x2) / pts(zm) 

pts(z2 ) ^ pts (xk) 




Z2 




RELATIVE 
■ SOURCE 
PACKET 
NUMBER 



?t9.V59S packet containing first byte of SEQUENCE 
HEADER video_PID=x 

PACKETCONTAINING FIRST BYTE OF SEQUENCE 
HEADER video_PID=y 

§SVS5>1 PACKET CONTAINING nRST BYTE OF SEQUENCE 
HEADER video_PID=z 



EP_map 



number_ot_stream/PIDs=3 

EP_map_for_ 
one_stream_PID (0) 



stream_PID(0)=x 



PTS_EP 


RSPN_EP 


start 


start 


pts(xl) 


XI 


pts(x2) 


X2 


pts(xk) 


Xk 



EP_map_for_ 
one_stream_PID (1) 



stream_PID(l)=y 



PTS.EP 


RSPN_EP 


start 


start 


pts(yl) 


Yl 


pts(y2) 


Y2 


pis(yn) 


Yn 



EP_map_for_ 
one_stream_PID (2) 

^stream_PID(2)=z 



PTS_EP 
start 


RSPN_EP 
start 


pts(zl) 
pts(z2) 

pts(zm) 


Zl 
Z2 

Zm 



Video EP_map 



[FIG.68] 



CUp 

AV STREAM 



SOURCE PACKET 
REFERENCING 
the STC_sequehce #1 



SOURCE PACKET 
REFERENCING 








► 





1 1'.' 1 


— ► 

















Xll Xln 



X21 X2m 



RSPN STC start#l RSPN STC start#2 



RELATIVE 
SOURCE 
PACKET 
NUMBER 



SOURCE PACKET CONTAD^IING FIRST BYTE OF SEQUENCE 
HEADER video_PID=x 

SOURCE PACKET REFERENCED BY RSPN_STC_start 
(DEFINED IN the STCJnto) 



EP_map_for_one_steram_ PID 
video PID=x 



PTS_EP 


RSPN_EP 


start 


start 


pts(xll) 


Xll 


pts(xln) 


Xln 


pts(x21) 


X21 


pts(x2m) 


X2m 



\ DATA BELONGING TO 
J STC_sequence #1 

boundary 



RSPN_STC_start #2<X21 



^ DATA BELONGING TO 
J STC_sequence #2 



[FIG.69] 



CUp 

AV STREAM 



video_PID=x video_PID=y video_PID=x 



program #1 



program #2 



program #3 



EP_map 

number_of_stream_PIDs=3 



RELATIVE 
SOURCE 
PACKET 

NUMBER 



EP_map_for_ 
one_stream_PID (0) 



EP_mapj[or_ 
one_stream_PID (1) 



EP_map_for_ 
one_stream_PID (2) 



stream_PID(0)=x 



stream_PID(l)=y 



stream_PID(2)=x 



[FIG.70] 



SYNTAX 


WO. OT 

bits 


Mnemon i cs 


ThOmbnailOi 






yersion_nuinber 


8*4 


char 


length 


32 




if aength!=0){ 






tn_blocks_start__address 


32 


bslbf 


iiiunber_of_thiimbnails 


16 


LilliioJL^X 


tn__block_size 


16 




nuinber_of_tii_blocks 


16 


iiimQbf 

UUIIOUJI 


reserved 


16 




for fi=Ol \<Jiu.fnb&r of thurnhnnil^* 1 






thumbnail.index 


16 


uimsbf 


thiimbiiail nictore format 






reserved 


u 




Dicture data size 






start_tn_block_number 


16 


uiinsbf 


x_picturejength 


16 


uimsbf 


y_picturejength 


16 


uimsbf 


reserved 


16 


uimsbf . 


} 






$tuffing_b]rtes 


8*2*L1 


bslbf 


forOc=0; k<number_ofjtnJblocks; k++){ 






tn_block 


tn_block_ 
size* 1024*8 




} 






} 






} 







Syntax of Thumbnail 



[Fia7i] 



EP_1ype 


MEANING 


0 


video 


1 


audio 


2-15 


reserved 



EP_typevalues 



[FIG.72] 



SYNTAX 


No. of 
bits 


Mnemonics 


EP_map_for_one_stream_PID(AO { 






for (i=0;i<A^;i++){ 






PTS_EP_start 


32 


uimsbf 


RSPNj:P_start 


32 


uimsbf 


} 






} 







Syntax of EP_map_for_one_stream_PID 



[FIG.73] 



i4 
u 

s 




[FIG.74] 



SYNTAX 


No. of 
bits 


Mnemonics 


TU_mapO { 






offset_tune . 


32 


bslbf 


time_iuiit_size 


32 


uimsbf 


number_of_time_unit_eiitries 


32 


tiimsbf 


for (y=0M<numb€r_of_time_unit_entrie5'M^) 






RSPN_time_uiiit_start 


32 


uimsbf 


} 







Syntax of TU.map 



[FIG.75] 



SYNTAX 


No. of 
bi ts 


Mnemon i cs 


ClipMarkOI 






version^number 


8*4 


bslbf 


length 


32 


uimsbf 


number_6f_Clip_marks 


16 


uimsbf 


for (i=0; i<number_of_clip_marks; i-H-) { 






reserved 


8 


bslbf 


mark^type 


8 


bslbf 


mark_time_stamp 


32 


uimsbf 


STC„sequence_id 


8 


uimsbf 


reserved 


24 


bslbf 


character^set 


8 


bslbf 


namejength 


8 


uimsbf 


mark^name 


8*256 


bslbf 


ref.thumbnail^index 


16 


uimsbf 


} 






} 







Syntax of ClipMark 



[FIG.76] 



Mark_type 


MEANING 


COMMENT 


Ox0O-0x8F 


reserved 


Reserved for PlaylistMarkO 


0x90 


Event-start mark 


MARK POINT INDICATING PROGRAM START POINT 


0x91 


Local event-start mark 


MARK POINT INDICATING LOCALSCENE IN PROGRAM 


0x92 


Scene-start mark 


MARK POINT SHOWING SCENE CHANGE POINT 


0x93-QxFF 


reserved 





mark^type 



[FIG.77] 



CPI_type 

in the HayListQ 


SEMANTICS OF mark_time_stamp 


EP_map type 


mark_time_stamp MUST INDICATE UPPER 32 BITS OF 33 
BIT LENGTH PTS CORRESPONDING TO PRESENTATION 
UNIT REFERENCED BY MARK 


TU_map type 


mark_time_stamp MUST BE TIME ON TU_map_time_axis 
AND MUST BE ROUNDED TO time_unit PRECISION. 
mark_time_stamp IS CALCULATED BY FOLLOWING 
EQUATION: 

mark_time_stamp = TU_start_time 



mark_type_stamp 



[FIG.78] 



SYNTAX 


No. of 
bits 


Mnemon i cs 


menu.thmb/mark.thmbO { 






reserved 


256 


bslbf 


ThumbnailQ 






for a=0;i<Nl;i++) 






padding_word 


16 


bslbf 


) 







Syntax of menu.thmb and mark.thmb 



[FIG.79] 



SYNTAX 


No. of 
bits 


Mnemonics 


ThCimbnailO{ 






version^number 


8*4 


char 


length 


32 


uunsbf 


if Oength !=0){ 






tii_blocks_start_address 


32 


bslbf 


number_of_thuinbnails 


16 


uimsbf 


tn_block_si2e 


16 


uimsbf 


number_of_tn_blocks 


16 


uimsbf 


reserved 


16 


bslbf 


for (i=0; \<number_pf_thumbnails\ i++) { 






thumbnailjndex 


16 


uimsbf 


thumbnailjpicture.format 


8 


bslbf 


reserved 


8 


bslbf 


picture.data.size 


32 


uimsbf 


start„tn_block_number 


16 


uimsbf 


x_picturejength 


16 


uimsbf 


y_picturejength 


16 


uimsbf 


reserved 


16 


uimsbf 1 


} 






stilfiSng^bytes 


8*2*L1 


bslbf 


forOk=0; k<number_ofjtnJblocks; k++){ 






tn_block 


tn_block_ 
size*1024*8 




} 






} 






} 







Syntax of Thumbnail 



CFIG.80] 



Thumbnail j)icture_format 


MEANING 


QkOO 


MPEG-2 Video 1-picture 


0x01 


DCF (restricted JPEG) 


Qk02 


PNG 


0x03-Qxflf 


reserved 



[FIG.81] 



(A) 



thumbnail_picture_format 



PICTURE DATA 



Thumbnail 0 





stufBng_bytes 



tn_blockO 



tn_blockO 




DVR MPEG-2 TRANSPORT STREAM 



Aligned 
unit 


Aligned 
unit 


Aligned 
unit 




Aligned 
unit 


Aligned 
unit 


6144 
BYTES ^ 





SOURCE 
PACKET- 0 


SOURCE 
PACKET- 1 


SOURCE 
PACKET- 2 




SOURCE 
PACKET- 31 


192 
BYTES ^ 

• 
• 






TP_extra 
header 


TRANSPORT 
PACKET 




4 

BYTES 


188 
BYTES 



Structure of transport stream of DVR MPEG2 



[FIG.83] 
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[FIG.84] 




[FIG.85] 



SYNTAX 


No. of 
bits 


Mnemonics 


source_packetO ( 






TP_extra_headerO 






trasport_packetO 






} 







source packet 



[FIG.86] 



SYNTAX 


No. of 
bits 


Mnemonics 


TP_extra_headerO { 






c<>py-Pe"njss>on_indicator 


2 


uimsbf 


arriyal_time_stanip 


30 


uimsbf 


) 







TP_extra_header 



copy jpermission 
..indicator 


MEANING 


00 


copy free 


01 


no more copy 


10 


copy once 


11 


copy prohibited 



copy permission indicator table 



[FIG.88] 
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[FIG.89] 
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[FIG.90] 




[FIG.92] 




CFIG.93] 




[FIG.94] 
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[FIG.95] 




[FIG.96] 



III 



27MHz 
X-tal 



27MHz 
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ARRIVAL 
TIME 
CLOCK 
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74 



Rmax 



SOURCE 
PACKET 
(DVRMPEG2 
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SMOOTHING 




SOURCE 


BUFFER 
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[FIG.97] 



SOURCE 
PAKETOF 
TSl 



SOURCE 
PAKETOF 
ATCl : / TS2 




ATC2 



VIDEO 
PRESENTATION 
UNIT OF TSl 



VIDEO 
PTSs 



□□□□□□□□□□□ 

VIDEO 
PRESENTATION 
UNIT0FTS2 



AUDIO 
PTSs 



AUDIO 
PRESENTATION 
UNIT OF TSl 




LAST VIDEO PACKET OF AUDIO 
TSl INPUT TO DVR STD OVERLAP 



T3 T5 



Timing diagram for inputting, decoding and displaying transport 
packet when transferring from given AV stream (TS1) to the next 
AV stream (TS2) seamlessly connected thereto 



[FIG.98] 
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[Name of Document] ABSTRACT 

[Summary] 

[Task] 

Determinatiorai of readout position and/or decode processing of AV 
stream are permitted to be quickly performed. 
[Means for solution] 

For every Cliplnfo, attribute information of AV stream are stored. 
The OflFset^SPN in Cliplnfo gives offset value of source packet No. with 
respect to the first source packet of AV stream. The time_controlled_flag 
indicates whether or not corresponding mode is recording mode where AV 
stream is recorded in such a manner that file size becomes proportional with 
respect to time elapse. Other data are data indicating type of AV stream, 
and/or data relating to date recorded. By referring these data, it is possible to 
perform determination of readout position of AV stream. 
[Selected Drawing] Fig. 46 
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